Let's add some rate counters to add visibility to the BTS on what is
happening in terms of received and/or transmitted RTP packets.
This should help during debugging any RTP related issues.
Change-Id: Ide674bde10b0e4b501d6a48947b983090342dfec
osmo_io permits us to use the io_uring backend, which should
significantly speed up the many small read/writes we're doing
on virt-um.
Change-Id: Icfe42da00fd446c38090055e2baa5d5e0ae5b70c
ctrl_cmd_send() is now a deprecated API function.
Change-Id: I663669a1bcf7b58d6a6175cbb51c333f5cfaedd7
Depends: libosmocore.git Change-Id Ic81af56e7ea6921ba39168727ef64c308e9c6754
We have licensed the code under GNU Afffero Public License,
and state that in the first paragraph as well as in the link
to the license. However, a paragraph in the middle stated
"see the GNU General Public License", which is somewhat misleading.
Let's fix that.
Change-Id: I37e503b195fe43e1da42c080900504ca8e682e76
All config file examples must be listed in EXTRA_DIST unconditionally.
Adding them conditionally results in incomplete release tarballs,
containing only 'osmo-bts-virtual.cfg' and failing to build.
Change-Id: I167027afde3cee40a3b52adfaec7bde91ba896da
Related: OS#6349
In early-Immediate-Assignment, the BSC sends the IMM ASS message
directly after it sent the Channel Activation message, and osmo-bts
should cache it until the Channel Activation is complete.
So far the code had a bug: it assumed that the lchan was on the same TRX
where the IMM ASS is transmitted -- but actually, 'trx' refers to the
BCCH channel's TRX, i.e. always c0.
Instead, look up the correct TRX by the ARFCN in the IMM ASS message.
Now, when frequency hopping is enabled, there will be no ARFCN in the
IMM ASS message, hence this fix does not work with frequency hopping.
Related osmo-bsc patch disallows this combination.
(To also support frequency hopping, osmo-bsc would need to modify the
RSL protocol: send the IMM ASS message as a custom IE directly as part
of the Channel Activation. Then it is always possible to correllate the
IMM ASS with a specific trx and lchan, no matter what information it
contains. However, early-IA is a "bad" feature in itself as it
"promotes" having high latency on Abis. It seems unnecessary to do extra
work to also support this odd use case for frequency hopping.)
Related: osmo-bsc I8d375e5155be7b53034d5c0be5566d2f33af5db0
Related: SYS#6655
Change-Id: Id9a930e5c67122812b229dc27ea2bfe246b67611
Current code evaluates as follows:
(trx->arfcn | is_uplink) ? GSMTAP_ARFCN_F_UPLINK : 0
while we want it to be evaluated as follows:
trx->arfcn | (is_uplink ? GSMTAP_ARFCN_F_UPLINK : 0)
Change-Id: Ida3d684968a3e4a45531d4b6d7b6af170e3e39f4
Fixes: CID#338165
If there's nothing to transmit over a CSD NT channel, both ends generate
NULL frames. Let's add an option to suppress GSMTAP output for those,
creating pcap files with less noise.
Change-Id: I85a2159cfaa01bfb4205c1462e3a9dbda68e4bad
Depends: libosmocore.git I2d9bd8eb4f0cd0f72c436996767b199429596917
In CSD (Circuit Switched Data) NT (Non-Transparent) mode, there
are RLP (Radio Link Protocol) frames inside the modified V.110.
wireshark alrady has a dissector for this, and we've introduced
a GSMTAP type for RLP some time ago. So with this patch, we now
generate such GSMTAP RLP frames.
Change-Id: I6a258458822bcb3fe7290a9b9b3d104beecda219
Get Attributes of Channel Object class that osmo-bts supports are added:
* ARFCN List
* Channel Combinations
* TSC
* HSN
* MAIO
Related: OS#6172
Change-Id: I56e067be9e5c17625c7da4e982b90927802f57b4
Two Get Attributes of Radio Carrier Object class that osmo-bts supports
are added:
* RF Max Power Reduction
* ARFCN List
Note: Only one ARFCN is reported, because synthesizer hopping is not
supported. The NM_ATT_ARFCN_LIST in the Set Radio Carrier
Attributes message currently allowes one ARFCN only.
Related: OS#6172
Change-Id: I49ab516c38a986520f1d3f6e26ddd20ee16688ac
Most Get Attributes of BTS Object class that osmo-bts supports are
added. Not supported attributes are:
* T200
* Starting Time
* HW Configuration
Related: OS#6172
Change-Id: I067c6bdea3c44d5a731bcfdcfe304c14629eb3db
Osmo-bts uses the new polling based LAPDm implementation.
The OML message NM_ATT_T200 is ignored, because T200 timeouts are set to
the minimal response time. Longer timeouts would cause lower throughput
in case of lost frames. Shorter timeouts would cause LAPDm to fail.
Related: OS#4074
Depends: libosmocore.git I6ebe83f829d7751ea9de1d90eb478c7a628db64c
Change-Id: Ic6d7902b13cf491daaa8752db78f9875387aeffd
An empty PDCH block contains no payload, sysmo-bts and similar BTS
models crash, because they expect the msg->l2h to be set. The function
l1sap_pdch_req() will not set msg->l2h for empty PDCH blocks, so these
models crash.
The current osmo-pcu does not send empty PDCH blocks to these BTS
models. But there shouldn't be a crash, if we receive empty PDCH blocks
over the PCU socket interface.
Change-Id: Icb52c896766425fcf453c65530c4c0b8d06b8821
If the channel is activated for immediate assignment, the initial data
link establishment on main signaling link with SAPI 0 must have L3
infomation included in the SABM message. If this is not the case,
release the data link without notifying BSC.
Related: OS#5971
Change-Id: I6819b51a876b8743c2d4a04165b7900723a1631c
Every BTS needs to have some graceful handling for the scenario
where it is time to send out a speech frame on TCH DL, but there is
no frame to be sent. One possible solution is to transmit dummy
FACCH, but this option is unattractive for TCH/AHS where FACCH
displaces two speech frames rather than one. A more elegant solution
is to emit a speech frame that is bad, causing the MS receiver to
declare a BFI condition to trigger substitution and muting procedure.
A bad frame is generated by gsm0503_tch_{afs,ahs}_encode() by setting
the payload length to 0.
Depends: libosmocore.git I82ce2adf995a4b42d1f378c5819f88d773b9104a
Related: OS#6049
Change-Id: I056f379715c91ad968f198e112d363a9009dc1c3
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: Ib51238a0e09d4484a539a7f822864189872698b6
When adding support for Circuit Switched Data calls, we had to enlarge
the burst buffer size to accommodate bits for a maximum of 24 bursts.
Let's take advantage of this by utilizing the currently unused part of
the Uplink burst buffer for storing bits of previously decoded blocks.
This eliminates the need to allocate additional memory for SACCH.
Change-Id: I15047cd1df4476054b36f05616e41f5297d9bfe5
Related: SYS#5114, OS#4794, OS#4795, OS#4796
In accordance with 3GPP TS 44.021, sections 8.1.6 and 10.2.3, the
transmission of idle frames to the DTE is mandated when no data is
received from the radio interface. An idle frame has all data,
status, and E-bits to binary '1' (excluding the alignment pattern).
This requirement is currently implemented for the Uplink, see
function csd_v110_rtp_encode().
However, 3GPP TS 44.021 does not explicitly specify whether the same
rule is applicable to the Downlink, perhaps assuming a continuous
stream of bits on the CSD-over-TDM link. Currently, we transmit
a sequence of binary '0' on the Downlink instead of idle frames.
* In non-transparent (RLP) mode, whether all bits in a block are
set to binary '0' or '1' has no impact, as both scenarios lead
to an incorrect FCS.
* In transparent sync mode, any filling be it binary '0' or '1'
is perceived as incorrect or unexpected.
* In transparent async mode, it is more logical to transmit a
sequence of binary '1,' which will be interpreted as
a sequence of stop bits.
Let's align the Downlink with the Uplink for consistency and transmit
idle frames when no data is available for transmission. The modified
60-bit V.110 frames exclude the alignment pattern, so sending a
sequence of binary '1' is enough to achieve the intended goal.
Change-Id: I0b25cfac41b6d8dcf3bfd9d46d51a9665f1b047a
Related: OS#1572
Even though it might have a somewhat higher performance impact,
opting for the common code path for FACCH by allocating a msgb
on heap is more favorable for both readability and maintainability.
This choice is preferred over directly calling
gsm0503_tch_fr_encode() and then using a 'goto' statement.
A similar strategy will be adopted in an follow up patch for CSD.
Change-Id: I67cb5c6f4d15149996e17c78a59d66db396da8ff
Related: OS#1572
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. Whenever the uplink on a voice group channel is free, the uplink
access burst detection is turned on. When the uplink access is granted
to a talker or when the calling subscriber has been assigned to the
channel, the uplink access burst detection is turned off until the
uplink becomes free again.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I92d6773a3a463eb747143c85aa149e54c1fda122
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. This is required for voice group/broadcast channels.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I61f232aa91191dae08404c1f08cad91964d74568
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. This is required for voice group/broadcast channels.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I9045437d52984b7abe00fbc815d7f83c62c0fb5a
- If the llist is flushed during rx rsp callback, when the flow is
returned to trx_ctrl_read_cb() it would access tcm which was in the
llist and end up in use-after-free.
- We need to store state on whether code path is inside the read_cb in
order to:
-- Delay transmission of new message if callback calls trx_if_flush()
followed by trx_ctrl_send(), since the trx_ctrl_send() at the end of
trx_ctrl_read_cb would retransmit it again immediatelly.
-- Avoid accessing tcm pointer if the callback called trx_if_flush(),
since it has been freed.
Related: OS#6020
Change-Id: Ibdffa4644aa3a7d219452644d3e74b411734f1df
This reverts commit 4444262a6a.
This commit introduced several side effects:
- tcm is left out of the l1h->trx_ctrl_list and hence won't be ever
retransmitted.
- Since tcm is removed before rsp callback, the llist may become empty
and if somehwere in the rsp callback a new message is enqueud it will
be sent immediatelly, and will be retransmitted again when
trx_ctrl_read_cb() calls trx_ctrl_send() at the end.
Change-Id: Ideb2d08ac8a2902bceeabfb055c59c9a13dbe3c0
Related: OS#6020
There are still some remains that are related to the old PCUIF v10
protocol version. Let's clean those up.
Related: OS#5927
Depends: osmo-pcu.git I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8
Change-Id: I04f7108c94c99c9920192177087748e8b89b3106
If frames are not deliverd fast enough to the DSP, bursts will get
dropped. The osmo-bts-sysmo process must have priority over other
processes, so it can deliver frames fast enough.
Related: OS#6199
Change-Id: I2394e6bbc00a1d47987dbe7b70f4b5cbedf69b10
While compiling:
vty.c:169:3: warning: 'is_config_node' is deprecated: Implicit parent
node tracking has replaced the use of this callback. This callback is
no longer called, ever, and can be left NULL. [-Wdeprecated-declarations]
.is_config_node = bts_vty_is_config_node,
^
Change-Id: I54c5aa5911611b181f80e76556b150f25dd5b60c
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo
to signal to the PCU that the direct PHY access for the sysmo-bts DSP
should be enabled. With time, support for other BTS models was added and
the flag became a synonym for "direct PHY access", so it makes sense to
rename it to "PCU_IF_FLAG_DIRECT_PHY"
Related: OS#6191
Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Change-Id: Ib556a93f7d7d7dbe1e96c4a0802bc802241b2b2d
DTX is not allowed for TCH/H in signalling mode, but *is* allowed
for TCH/F in signalling mode.
Change-Id: I91cfd8f561eb47a5fc48c0682d56331a1d69aded
Related: OS#6168
The current implementation does substitute all missing meas samples
with dummy -SUB measurements and then complain about exceeding
amount of -SUB samples.
Change-Id: Iab84f4b64b645486e2f115b0f82ee2f27eb992bc
Related: OS#6168
3GPP TS 45.008, section 8.3 defines TDMA Fn subsets, which shall
always be transmitted when DTX is employed, only for:
* TCH/F in signalling mode (but not for TCH/H),
* TCH/H and TCH/F in data mode (CSD) [*],
* TCH/FS, TCH/EFS, and TCH/HS.
For channel modes employing AMR codec, in particular:
* TCH/AFS, TCH/WFS, O-TCH/WFS,
* TCH/AHS, O-TCH/AHS, O-TCH/WHS,
there exist no fixed TDMA Fn subsets, but DTX is still permitted.
For those we expect at least one SACCH frame, plus a variable
number of speech frames (0 or more).
[*] Handling of data modes is fixed in a follow-up patch.
Change-Id: Ied477528d77871dd7e3b5b7b433a4e33bca40011
Related: OS#6168
It was reported that osmo-bts-sysmo is crashing due to a TCH.ind
primitive being received by l1sap_tch_ind() for an lchan, which
is operating neither in speech nor data, but in signalling mode.
It's not clear which scenario is causing this situation. My best
guess is that one or more TCH.ind primitive(s) remain waiting in
the lower layers and bob up right after the channel mode change.
This can happen, for instance, when a dynamic timeslot gets
switched from TCH/F or TCH/H to PDCH or SDCCH/8.
Change-Id: I2d270ab654fdd9d19d1708ff6c4b4e902bd5d0a3
Fixes: d1f8f3429 "l1sap: proper rate adaptation for CSD"
Closes: OS#6180
Fix OsmoBTS not restarting if e.g. an external gsmtap IP is configured
that is currently not available. Also make the service files more
consistent with other Osmocom projects.
Partial revert of ae2473c2 ("systemd: Do not restart with a broken
config file or such").
Related: SYS#6581
Change-Id: Ieeed858c159839ebaa27b2be35a597fb86874c4b
System Information Type 10 uses short L2 header that is transmitted as
Bter UI frame. The complete frame is sent by BSC, including short L2
header. Only the SACCH layer 1 header is added by the BTS.
A switch() statement is used, so other System Information with short L2
header can be added in the future.
Change-Id: Ifede42bfd84ea5914b559a20ae68f594d2ee1a5c
Do not forward any message that is received on the uplink to LAPD while
the uplink is not active. If the MS did not recognize (fast enough) that
the uplink is free, it may continue to transmit LAPD messages. A
response by LAPD to these messages is not desired and not required. If
LAPD would respond, it would cause stopping transmission of UPLINK FREE
messages. No MS could access the uplink anymore.
Note: UPLINK FREE messages are repeated automatically until a different
message is transmitted.
Related: OS#5781
Change-Id: I5075115123055b2997481f56ddf473430a1dc9e3
The RSL link is configured/set up by the BBTRANSC NM object, hence move
it to the appropiate substruct.
Related: OS#5253
Change-Id: I62937cbd81c27274b9f5f70d454d5319a6898c7b
This is a preparation commit towards delaying connection of RSL tcp
socket until the BBTRANSC object is OPSTARTed, as it is the case already
in nanoBTS.
Related: OS#5253
Change-Id: Ia571ec19e9e8f8a6d7c2554642aab0afe1b4b917
These attributes are listed in 3GPP TS 52.021, Table 2/GSM 12.21.
Many attributes are still unhandled, but at least something.
Change-Id: I94702c503fea5b42d84673ccd7065c9323b733b8
Related: OS#4505
The previous logic was wrong, since it was only reactivating the channel
if the provided BS_AG_BLKS_RES was != 1.
Example previously broken scenario:
1- osmo-bsc user sets "channel-descrption bs-ag-blks-res 2" during
osmo-bsc startup in osmo-bsc.cfg
2- osmo-bsc user uses VTY to change it to "channel-descrption
bs-ag-blks-res 1"
3- osmo-bsc user uses VTY to deploy the new config: "bts <0-255>
resend-system-information"
Step 3 would fail beforehand, ending up in a NO-OP.
Change-Id: Ibc118e11c64f04de55cb7b94d8bf2c84b431774d
Other bts models like sysmo,lc15,oc2g properly handled
rel_act_kind=LCHAN_REL_ACT_REACT under the bts_model_lchan_deactivate()
implementation, but bts-trx didn't.
As a result, when BCCH_INFO(SYSINFO_TYPE_3) coming from BSC (RSL)
containing a different BS_AG_BLKS_RES triggers CCCH re-activation,
it would only deactivate it but not re-activate it.
That means no SIs were being scheduled if bts was configured with
"channel-descrption bs-ag-blks-res 2" in osmo-bsc.cfg, and phones would
not see the cell.
Related: OS#1575
Change-Id: I61e1681fbaa2c993b529d58b581c99166b62bda3
At the moment we do not print the SAPI, nor the msg_id when we send a
confirmation back to the PCU
Change-Id: Ibd5b4225e597b69eaabaeee437fb637943a55602
elated: OS#5927
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI
to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. In
both cases we send a confirmation back to the PCU. For details see
coresponding patch in osmo-pcu.git (see Depends)
CAUTION: This patch breaks compatibility to current master osmo-pcu (See
also "Depends")
Related: OS#5927
Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
Depends: osmo-ttcn3-hacks.git Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458
Change-Id: I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
The PCU now sets a confirm flag in struct gsm_pcu_if_pch in case the MAC
block (data) requires a confirmation when sent. Use this confirm flag
instead of making the decision locally based on the MAC block contents.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I3364d2268bdef9c4d2feeb8e3d51a64e34bca68c
The function bts_agch_dequeue() is not used outside of bts.c, so it can
be a static function.
Change-Id: If86293ebbd99d6550022aeb8721d40bca5fc04fc
Related: OS#5927
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Change-Id: Icf85f60ae86fbe1f3b98e1457c0598bb09cb08c5
Related: OS#5927
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Related: OS#5927
Change-Id: I779605858648e2a1c202c37e197a6e32e6ea3786
The function pcu_tx_pch_data_cnf() gets a parameter fn (frame number).
This parameter is then used to populate the member fn in
gsm_pcu_if_data_cnf_dt of the PCUIF protocol. However, the PCU only uses
this parameter for logging and nothing else. Hence it it is not needed
and we can remove it.
Related: OS#5927
Depends: osmo-pcu.git I35bc99eaec5d0287ae3916bc668f0babaddfd6ce
Change-Id: Id1c8fa77725129ec2ea7e92e1df493f35a277659
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: Ie6b34d5df64f4bed6b14581c7957dcba6af44136
The rate adaptation algorithm is the same for both transparent and
non-transparent channel modes. The only difference is that the
E-bits in the modified CSD frames carry data, like the D-bits.
Change-Id: Ib0d9346d7a8e30b8a8e4b08ee04846ba7d12b3fb
Related: OS#1572
The E1/E2/E3 bits are set based on out-of-band knowledge of the
current user data rate. The actual bit values are defined in
3GPP TS 44.021, Figure 4 "Coding of data rates".
TODO: this is only valid for transparent services,
for non-transparent services see 3GPP TS 48.020.
TODO: lchan->csd_mode is never set to the actual CSD mode...
Change-Id: I1a14597dff746cf975140b294400a2cc05badccd
Related: OS#1572
Since 95407f3f osmo-bts-trx supports scheduling all CSD specific
channel rates, however the rate adaptation was missing.
On the radio interface we deal with CSD-modified V.110 frames, which
need to be converted to normal 80-bit V.110 frames (RA1'/RA1), which
in turn need to be batched and sent in RFC4040 "clearmode" 160 octet
RTP payloads (RA1/RA2 as per I.460).
Note that this patch comments out TCH/F14.4 in bts_supports_cm_data(),
so that all channel allocations for this mode would be NACKed. The
reason for this is that the rate adaptation functions for TCH/F14.4
are different than the RA1'/RA1 and the RA1/RA2.
For more information, see:
* 3GPP TS 44.021, section 8 (functions RA1'/RA1)
* ITU-T I.460, section 1.1 "Rate adaption of 8, 16 and 32 kbit/s streams"
Change-Id: I5e3701ad52d5d428fd02caff037881045f2d0a02
Related: OS#1572
UPLINK ACCESS (RACH on TCH) was enabled for osmo-bts-sysmo only. Now it
is also enabled for:
* osmo-bts-lc15
* osmo-bts-oc2g
* osmo-bts-trx
* osmo-bts-virtual
Change-Id: Iae0db6bfcf6629c114436a79648e832c82835abe
The abstract representation of the rest octets are moved to the header
file, so that the test case can include it. append_p*_rest_octets()
function become externally available for test.
Change-Id: Ifa5be8998b671160e38af1be707e040b00d407b8
Related: OS#5781
According to TS 44.018 the UPLINK FREE message must be repeated when the
uplink is marked as free. The BSC sends the UPLINK FREE message once and
the BTS repeats it until UPLINK BUSY (uplink blocked by BSC) or
VGCS UPLINK GRANT (talker accesses the uplink) is sent.
It is important to stop sending UPLINK FREE message when a talker
accesses the uplink and before the VGCS UPLINK GRANT message is sent, so
that stopping must be controlled by the BTS.
Related: OS#5781
Change-Id: Ia23c59f5e9a73bbc384fbc317a2cfcf707e3c28f
When a VGCS/VBS call is established in a cell, NCH is used to notify
about ongoing calls to idle subscribers. Additionally Notification/FACCH
is used to notify subscribers in dedicated mode. This is performed by
broadcasting this messages to all active dedicated channels. The mobile
station can then indicate the call, so the user can join the call.
More importaint is the notification of the calling subscriber's MS,
which initiated the call. This is done on the early assigned channel.
The MS must know on which channel the call is placed. After leaving the
uplink, it must know where to access the uplink the next time.
Change-Id: I3ed14fa54a907891e492a7ada8e745a2c56cd46d
Related: OS#4851, OS#5781
Do not send notifications here. The notifications are sent on the NCH.
The NLN is used to indicate a change on the NCH, so that the MS will
read the NCH then.
If NLN is not sent towards MS, it will not read NCH to get an updated
list of ongoing calls. Also, it will not allow making VGCS/VBS calls and
might indicate that ASCI is not supported in this call. (Tested with
GPH-610R.)
Change-Id: I22e584b70fd14d8bdabb28cf5de3d4647f37425a
Related: OS#5781
Currently the rest octets contain Notification List Number (NLN) and
NLN status and the "Channel Needed" (CN3 / CN4) fields for mobile
identities.
The existing encoding of CN3 / CN4 in Paging request type 3 has been
replaced.
The missing encoding of CN3 in Paging request type 2 has been added.
Change-Id: I6e33a6d38d4c7b124de35b53d219b64bb881ba66
Related: OS#5781
The location of the NCH is defined by the rest octet of System
Information 1. If NCH is defined, the given CCCH blocks are used for NCH
instead of AGCH/PCH.
The current list of VGCS/VBS call notifications is transmitted on the
NCH. If there is no notification, an empty notification is transmitted
on the NCH.
The Notification List Number (NLN) is used to indicated new
notificaitons. Only the last notification (or empty notification)
indicates NLN. This way the MS can determine after two equal NLN that
the complete list has been recevied.
Change-Id: I82fdaba3faaced76267a99ae14a5458a1b41fdaa
Related: OS#5781
When BCCH INFO is received via RSL message, the rest octet of the System
Information 1 message is parsed to get the position of the NCH. The
position is stored in the gsm_bts structure. If the position is not
present int the rest octet, the stored value is set to negative.
Change-Id: I799a27179d478d4ff577d8bc47ae524834851e85
Related: OS#5781
It may happen that only FACCH is available for transmission, so msg_tch
would be NULL in this case. Check it before dereferencing.
Change-Id: I0e7d5634b5223bc246badbb8e94b620c967ab121
Related: OS#1572
This tells our TTCN3 BSC tests to perform VBS/VGCS related procedures on
RSL.
Change-Id: I9ed1b20985d2ce3be31942d3e9df5cad513a0bfd
Related: OS#5778, OS#5779
Reactivation will modify parameters on an already activated channel. On
a VGCS/VBS channel it can be used to prepare channel for assignment of
the mobile station to it.
During assignment the channel is reactivated. The timing advance of the
mobile station is given. The uplink is activated and is waiting for the
mobile station to establish, to complete the assignment.
For reference see patent EP 1 858 275 A1.
Change-Id: I77f413cf70c2f5f8e8f525686eee40548521c71b
Related: OS#4851
Random access is allowed on VGCS / VBS channels to access the uplink or
to detect listeners. Uplink Access from a listener is only reported once
after activating the channel. Uplink Access from a talker is reported
each time the uplink becomes occupied. RSL TALKER/LISTENER DETECT
messages are sent to the bsc.
The VGCS UPLINK GRANT message is sent by the BTS itself. Timer T3115 is
used to repeat the message up to NY2 times until one valid frame is
received from the MS (CM service request). The UPLINK BUSY / UPLINK FREE
message must be sent by the BSC.
The uplink is released by UPLINK RELEASE message from the MS or from the
BSC. Afterwards the UPLINK FREE message causes the MS to leave the
uplink without any acknowlege. An RSL REL-REQ must be used to terminate
the link locally. (Without layer 2 DISC procedure.)
Change-Id: I1bd07ab6802341b09a06e89df356665ffaf6d2bf
Related: OS#4851
When an IMMEDIATE ASSIGNMENT MAC block (from PCUIF) is added to the
paging queue, then also an IMSI is required. The paging queue uses the
last three digits of the IMSI to calculate the paging group. In case no
IMSI is given, the MAC block is rejected. This was handeled differently
before. Even an IMSI of length 0 would still be interpreted as "000" and
not rejected. See also:
I9f3799916e8102bf1ce0f21891f2d24f43091f01
Let's restore the behaviour we had before and accept short IMSI
strings again.
Change-Id: Iab1c3f1c39dd59bb53aa74b2c9e9e135e3985e0b
Related: OS#6099
In f2c902c2 I accidentally bumped the logging level for PDCH decoding
errors to LOGL_NOTICE, making osmo-bts-trx spam the logging with
hundreds of 'Received bad data' messsages. Revert this.
Change-Id: Idb963f1a779dfa172825f6d481740cb0c4165485
Fixes: f2c902c2 "osmo-bts-trx: unify and enrich 'Received bad data' logging"
The FACCH/[FH] coding rules are specified in 3GPP TS 45.003, sections
4.2 and 4.3. The key difference is that unlike with speech channels,
FACCH does not replace data frames completely, but disturb a fixed
amount of bits fom them. This is why we need to use separate
gsm0503_tch_[fh]r_facch_{en,de}code() API for data channels.
Change-Id: I4c6736e84c271240d457998de688c0baf59fe578
Depends: libosmocore.git I0c7a9c180dcafe64e6aebe53518d3d11e1f29886
Related: OS#1572
* enlarge the maximum burst buffer size to 24 * (2 * 58) bytes;
* enlarge per-l1cs Uplink burst mask to hold up to 32 bits;
* enlarge per-l1cs Uplink meas ring buffer to 24 entries;
* add new meas modes: SCHED_MEAS_AVG_M_{S22N22,S24N22};
Change-Id: I08ffbf8e79ce76a586d61f5463890c6e72a6d9b9
Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Related: OS#1572
The goal is to unify encoding functions in tx_tch[fh]_fn(), so that
in a follow-up change adding CSD we could use a switch statement.
Change-Id: I15318e497b236128f779769e4fa99f307ea431ea
Related: OS#1572
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
cm->spd_ind can take only three values defined in enum rsl_cmod_spd:
0000 0001 RSL_CMOD_SPD_SPEECH
0000 0010 RSL_CMOD_SPD_DATA
0000 0011 RSL_CMOD_SPD_SIGN
According to 3GPP TS 48.058, section 9.3.6, all other values are
reserved, so expecting RSL_CMOD_CRT_TCH_{GROUP,BCAST}_{Lm,Bm} there
is wrong. These values are part of enum rsl_cmod_crt, so the right
field would be not cm->spd_ind, but cm->chan_rt.
Let's check these channel types in a separate stage, before checking
the requested codec. Group them with VAMOS specific types for the
sake of consistency.
Change-Id: I914c84be04da819df9e60e2f5ecc5bac9b61b2e5
Fixes: 44c94fdea "validate RSL "channel rate and type" against VGCS/VBS flags"
Related: OS#4851
The RSL "Channel rate and type" field from the RSL Channel Mode IE
in RSL_CHAN_ACTIV and RSL_MODE_MODIFY_REQ messages is the only place
where the BSC differentiates between a normal TCH and the special
TCH modes used in VGCS or VBS. Let's copy this field from the RSL
message into the lchan state, so that BTS models can actually (in
subsequent patches) reflect it when activating the L1.
Change-Id: I6d531bf528bcb81f44d91336471a46ef790d7646
Related: OS#4851
We already have specfied (but not yet implemented BTS_FEAT_{VBS,VGCS}).
Let's add code to validate "channel rate and type" compatibility
in bts_supports_cm() once a BTS model would actually exhibit those
feature flags.
Change-Id: I5e7f65b44cef6e2f7ad4f152f80a1686a4f511e3
Related: OS#4851
This adds very minimalistic support for notification of VBS/VGCS calls.
Minimalistic in that we
* only notify via PCH (not via NCH or FACCH)
* only include notification in otherwise empty PAGING TYPE 1
This means that notification will cease to work once the PCH becomes too
loaded and we never would send otherwise empty PAGING TYPE 1 anymore.
Change-Id: I6f6f72d9a0123cb519b341d72a124aaa2117370e
Requires: libosmocore.git I9586b5cb8514010d9358fcfc97c3d34741294522
Related: OS#5781
As we subsequently add ASCI related features to the code, it makes
sense to have a specific log sub-system for it.
Change-Id: I8ea3e61df35175bd74110b2f41994c99da3e2858
Related: OS#4851
The NLN + NLN-Status are optional parts of P1 rest octets; they can
be used to support the "Reduced NCH monitoring mechanism" as described
in Section 3.3.3.3 of TS 48.018.
The patch just adds encoder capability but doesn't yet make use of it.
Change-Id: I961842c3fec151e149f72a4f36279ce4b979795e
Related: OS#5781
OsmoBTS still uses the deprecated version 10 of the PCUIF protocol.
OsmoPCU is still compatible to version 10, but to maintain a clean
interface it is planned to drop the support for version 10 in the near
future.
Moving to PCUIF v.11 essentially means using the "Direct TLLI" method to
convey IMMEDIATE ASSIGNMENT and also PAGING COMMAND messages through the
PCU socket. This means in particular that we use a TLLI as an identifier
to confirm IMMEDIATE ASSIGNMENT messages towards the PCU (PAGING COMMAND
is not confirmed at all). Also we now use struct gsm_pcu_if_pch_dt to
parse the incoming PCU_IF_SAPI_PCH_DT, which is much cleaner than using
offsets in a buffer.
Change-Id: I25816ac12e63cc6b641eb414e6bc7eaa9c85fc25
Depends: osmo-ttcn3-hacks.git I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
Depends: docker-playground.git Ia28bc0d6d3cbfe63be19443db86631fb67bb80fb
Related: OS#5927
The payload size for some CSD channel types is bigger than what an
uint8_t can represent, for instance 290 bytes for TCH/F14.4.
Change-Id: Id75c55509a017d14dfab2a7b4c67e0742125a113
Related: OS#1572
This commit aims to make the argument naming/ordering more consistent:
* rename l2/l2_len and tch/tch_len to data/data_len;
* common arguments first (consistent ordering), specific last.
Change-Id: I3d8c90b82f2a55b0c5c2d6b4efb8fd962508534d
Related: OS#1572
The default of 10 messages introduced recently is too small, specially
when using osmo-bts-trx, where clock drifting and CPU scheduling can
cause skewing and hence generation of 2-3 FNs (* up to 8 TS) at once,
hence filling the PCUIF queue with more than 10 messages in a given
moment.
Fixes: c938a95e25
Change-Id: I7ababfc6cdf20196889fb542a8040128b3c118b5
Fixes memleak in case of connected PCU process being suspended without proper close on socket
Related: OS#5774
Change-Id: Ia6e61dda4b3cd4bba76e6acb7771d70335062fe1
With this change the application of ECU in the uplink path becomes
consistent across all OsmoBTS models, enabled or disabled per vty
config setting "rtp internal-uplink-ecu". An additional behavioral
change from the previous trx-model-only implementation is that ECU
insertion is now done after the link quality check in l1sap, thereby
fixing the bug where this quality check would sometimes suppress
ECU output and replace it with BFI markers in RTP.
In the new implementation when the internal ECU is enabled and
available for the selected codec (currently FRv1 only), the RTP output
will gap (standard representation of BFI in RTP) only during DTXu
pauses as indicated by a received SID frame (either valid or invalid),
and the SID frame that triggers the switch from ECU mode into pause
mode is reliably emitted in RTP.
Related: OS#6040
Depends: I3857be84bba12aaca0c2cca91458b7e13c5a642a (libosmocore)
Change-Id: Iac577975c9ab50cb8ebbc035c661c1880e7cecec
In preparation for moving the now-optional application of ECU in UL
path from osmo-bts-trx model-specific code to the common layer,
move ECU state allocation and freeing from trx model to l1sap.
Related: OS#6040
Change-Id: Ic98a2eb26b5a99bc4a89ad07ae87c9a86b921418
Current osmo-bts-trx includes a provision for invoking ECUs from
libosmocodec in the UL path from the channel decoder to the RTP
output. This pre-existing implementation is counter to the spirit
of 3GPP specs (a BTS should merely mark BFI conditions in its UL
output, as opposed to actively modifying the frame stream with an ECU),
inconsistent between different osmo-bts models (only in -trx and no
others), and inconsistent even within osmo-bts-trx itself, where
the link quality check in l1sap will sometimes suppress the output
of the ECU - a quirk which the designers of the current mechanism
most certainly did not intend.
The solution decided upon in OsmoDevCall on 2023-06-21 is to make
this ECU optional per vty config, and move it from the trx model
to the common layer to resolve the inconsistencies. Implement the
first part: make the ECU application optional per vty config.
For backward compatibility with existing deployments, the new
"rtp internal-uplink-ecu" setting is enabled by default on osmo-bts-trx
but not on any other models.
Related: OS#6040
Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
Connecting to OML and PHY is done in parallel. The PHY connection will
always be done first, mute PHY until OML is also ready.
As Pau suggested, move dispatch of NM_EV_SW_ACT to a callback of
trx_rf_lock to have the events serialized and therefore deterministic.
Fixes: SYS#6496
Change-Id: Ia1769f952fa787202a442a33db5ed4a1f7cbe9c3
Do not dispatch NM_EV_SW_ACT to trx->mo.fi and trx->bb_transc.mo.fi when
RF-ACT.conf was not successful. Running this code path anyway looks like
a leftover from when bts_shutdown used to exit osmo-bts.
Change-Id: I342187604f4c72303e393ce6925b94d610bfa8fa
Keep the l1sap specific wrapper because we still want to assert().
Change-Id: I7097ba87f42689d2336014da9173cadbdaa9fdab
Depends: libosmocore.git I8cbd31226754e95887358ed83a928e2f567f4cf3
Run bts_update_status in trx_mute_on_init_cb like in the default
callback mute_rf_compl_cb.
Related: SYS#6496
Change-Id: Ib73a33a82fbb86ead3569a6bb22fb001c55354d4
The function signature of rtppayload_is_octet_aligned has a parameter
rtp_pl for the payload and a parameter payload_len for the length of the
payload, while other functions use rtp_pl and rtp_pl_len.
Change-Id: I8a0e0357aab2a78e25811f66b1b870e8c6ebffe9
when osmo-bts receives a MAC block from osmo-pcu through the PCUIF it
puts it in the review queue without further interpreting it. This also
means that it will send confirmations to the PCU for IMMEDIATE
ASSIGNMENT and PAGING COMMAND. This is not entirely correct because only
IMMEDIATE ASSIGNMENT messages should be confirmed. osmo-pcu has no
problem with this since it silently drops the confirmations for PAGING
COMMAND messages. This peculiarity of the PCUIF implementation makes the
confirmation logic hard to understand, so let's add some logic to
osmo-bts that makes sure that only IMMEDIATE ASSIGNMENT messages are
confirmed.
Related: OS#5927
Change-Id: I8b8264d28b1b1deb08774cdba58dd4c6dafe115d
The function paging_add_macblock takes a data and length parameter. The
first three byte of that string are the last three digits of the IMSI
from which the paging group is calculated.
As the layout of this data buffer is a property of the PCUIF interface
API, we should do this separation outside of paging.c. Also we should
supply the IMSI as a valid null terminated string since PCUIF v.11 also
uses this format.
Change-Id: I9f3799916e8102bf1ce0f21891f2d24f43091f01
Related: OS#5927
In all Uplink lchan handlers we do memset() the Rx burst buffer on
bid=0 and there is no need to do that again for NOPE.ind.
Change-Id: Ia6803b8606d86bd2d011fe21f7a540d2115aa654
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
In speech TCH operation, there will always be times when a speech frame
needs to be transmitted on the downlink, but there is no frame available
to transmit (gap in the incoming RTP stream), or the logic of DTXd says
that no frame shall be transmitted at this FN, but we are not doing
physical DTXd. Previous osmo-bts-trx code sent dummy FACCH during such
conditions, but this approach is bad for TCH/HS where we would like to
transmit good speech frames or speech frame gaps one 20 ms frame at a
time, rather than take out pairs of frames for dummy FACCH/H. Other
BTS models (sysmoBTS PHY) send out invalid speech blocks with inverted
CRC3 under the conditions in question - do the same in osmo-bts-trx.
The present change modifies osmo-bts-trx TCH DL frame gap behavior
only for TCH/FS, TCH/HS and TCH/EFS; for all other channel modes,
including AMR speech, the previous behavior of sending dummy FACCH
is left unchanged.
Depends: Iade3310e16b906efb6892d28f474a0d15204e861 (libosmocore)
Change-Id: I78106802a0aa4af39859c75d29fe0e77037899fe
Suppose we receive RTP from the uplink of another BTS, and the
UL-handling BTS has channel-decoded an HR1 frame which it deems
(per GSM 06.41 section 6.1.1) to be a valid SID, even though it is
not a perfect, error-free SID. How will this SID frame be
represented in RFC 5993 transport? My reading of the RFC tells me
that the UL-handling BTS will need to apply an operation like our
osmo_hr_sid_reset() to the payload before sending it out in RTP -
but because the text of the RFC does not explicitly address this
scenario, others may have interpreted it differently.
If we receive an RFC 5993 RTP payload in which FT is set to 2,
indicating good SID, but the actual HR payload is not a perfect SID
(the SID field is not all 1s), the only reasonable interpretation
of such occurrence is that the sender of this payload was another
BTS whose implementors interpreted the RFC as not requiring them
to rejuvenate the SID codeword prior to RTP output. Therefore, let's
treat such payloads as valid SID for our DTXd logic, and rejuvenate
the SID codeword ourselves.
Change-Id: Ife00de6220a8ca7cc180a61734497f1acb7f5b83
osmo-bts-trx always accepted (and previously required) HR1 codec RTP
input in RFC 5993 format; currently we accept this RTP format as
input for all BTS models, but no longer require it. However, we
have never applied any checks to this format's ToC header, even
when we previously required it in osmo-bts-trx. Check this header
and reject invalid payloads that just happen to have the same octet
length as valid ones.
Change-Id: If16d38641913bb46bcd7cc11685407ed17136bfe
GSM 06.31, 06.41 and 06.81 are the respective DTX specs for FR, HR
and EFR. In each of these specs, section 5.1.2 specifies the
expected shape of radio downlink in the presence of SIDs: one SID
frame after each talkspurt (after speech frames), and one SID frame
in every SACCH-aligned position every 480 ms (every 240 ms for HR),
or if the actual SACCH-aligned position is taken up by FACCH,
then just one SID frame as soon as possible after that FACCH -
and no transmitted SID frames in other positions.
This just-referenced spec section was written with the assumption
that it will only be applied when DTXd is enabled - however, if
the RTP stream for call leg B DL comes from call leg A UL (TrFO),
then we are going to receive SID frames in the stream intended for
our DL even when DTXd is disabled or not supported altogether.
The easiest solution is to apply FR/HR/EFR DTXd logic whenever
the incoming RTP stream contains SID frames, irrespective of physical
DTXd enable/disable state. If we apply such "logical DTXd" when
physical DTXd is disabled, the BTS model PHY will end up transmitting
induced BFIs (dummy FACCH or inverted CRC3) in those frame positions
where the "logical DTXd" function says "please transmit nothing".
The point remains, however, that the prescribed SID shape on the
radio downlink (expected positions of SID frames) won't happen on its
own: in the case of TrFO, whichever SID frames are present will be
in wrong positions for leg B DL, and even in the case of transcoded
calls the responsibility for DL SID shaping cannot be placed on the
RTP stream source because that source won't know where SACCH alignment
will lie. Therefore, the necessary DL SID reshaping has to be done
in the RTP stream receiver in OsmoBTS.
Related: OS#5996
Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
There is no more need to access the UL/DL buffers via pointer to pointer
thanks to the previous patch [1] moving the memory management routines
out of the logical channel specific Rx/Tx handlers.
Change-Id: Ib1e8e86ac60a7ac9b0415ef66b609eaa33443c19
Related: [1] c45e03726af8a2b46b7166b3c47bc666ba933a69
It's a lot cleaner if the Rx/Tx burst buffers are allocated and free()d
in one place rather than in each lchan handler individually. Allocate
the buffer(s) during the lchan activation, free() on deactivation.
Regardless of lchan type, allocate the maximim size of 4 * (3 * 2 * 58)
bytes, which is sufficient to store 4 8PSK modulated bursts. This way
we reduce the load on the memory allocator at the cost of memory
consumption, what should not be a big problem.
Change-Id: I6a5f76023fc492786076a63016f81285b3576c33
Depends: libosmocore.git I1c38ccc2b64ba9046bb3b1221d99cc55ec493802
Related: OS#1572
The new vty option "rtp hr-format (rfc5993|ts101318)" selects the
RTP output format to be used for HR1 codec, consistently across
all models. The default is set to match legacy behavior: ts101318
on osmo-bts-{lc15,oc2g,sysmo} and rfc5993 on osmo-bts-trx.
On models where no legacy behavior is applicable, the default is
set to rfc5993 as a forward-looking measure - see OS#6036.
Closes: OS#5688
Change-Id: I168191874a062429a57904511a1e89e3f588732e
As a preliminary step before making the RTP output format from
OsmoBTS configurable with a vty option, we need to make the internal
format consistent across all models. The "natural" output from a
"pure" GSM 05.03 channel decoder is TS 101 318, which is also the
output format of all currently supported proprietary PHYs - adopt
it as our internal format.
Related: OS#5688
Depends: I6e75ca95409b5c368e8e04d0e0aba41e0331d9e6 (libosmocore)
Change-Id: I41bce6226964975cb85aea89e4c0f9e11e4929b8
As of commit 1160cabefb, the common layer of osmo-bts accepts both
TS 101 318 and RFC 5993 formats for HR1 codec, and always passes
the more basic TS 101 318 format to the BTS model. Unfortunately,
osmo-bts-trx has model-specific code checking the payload length
that was overlooked in that patch, causing breakage. Fix that bug.
(The actual channel encoding function in libosmocoding already
accepts 14-byte payloads.)
Related: OS#5688
Fixes: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Change-Id: I0e251faeffb76d2604a4100c848141d239d1d86f
There exist two different RTP encoding formats for HR1 codec: one
"simple" format defined in ETSI TS 101 318, and an extended format
(adding a ToC octet) defined in IETF RFC 5993. Following the
liberal-accept clause of Postel's law, we would like to accept
both formats. Implement this feature by first converting all HR1
RTP inputs to the more basic TS 101 318 format at the point of
input preening, and then consistently using this basic format
internally.
Related: OS#5688
Depends: I13eaad366f9f68615b9e9e4a5f87396a0e9dea0f (libosmocore)
Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Up until now, our approach to validating incoming RTP payloads and
dropping invalid ones has been to apply the preening function inside
l1sap_tch_rts_ind(), at the point of dequeueing from the DL input queue.
However, there are some RTP formats where we need to strip one byte
of header from the payload before passing the rest to our innards:
there is RFC 5993 for HR codec, and there also exists a non-standard
extension (rtp_traulike) that does a similar deal for FR and EFR.
Because of alignment issues, it will be more efficient (avoids memmove)
if we can do this header octet stripping before we copy the payload
into msgb - but doing so requires that we move this preening logic
to the point of RTP input before enqueueing. Make this change.
Related: OS#5688
Change-Id: I7fc99aeecba8303b56d397b8952de5eea82b301e
As detailed in OS#6033, osmo-bts-trx was emitting its own invented
packet formats to signal BFIs (bad frame indications), different
from the vty-configured ("rtp continuous-streaming" or not) BFI
signaling method implemented in l1sap and used by all other BTS models.
In the case of EFR codec, the made-up BFI format previously used by
osmo-bts-trx caused EFR operation to be broken: a spec-compliant EFR
decoder on the receiving end of the RTP stream (a network transcoder
or the MS on the other GSM call leg) would receive and decode garbage
EFR frames of 244 zero bits instead of invoking the spec-defined bad
frame handler, causing bad audio artifacts for the user. The same
situation would also happen for FR1 codec, but the application of
ECU masked this bug: with the ECU invoked in the UL output path,
the BFI emitting code for FR1 never executed.
In the case of AMR and HR1 codecs, the model-specific BFI packet
format of osmo-bts-trx is currently harmless, but:
* The extra code adds unnecessary complexity;
* BFI packet formats are inconsistent between osmo-bts-trx and
other OsmoBTS models;
* BFI format is even inconsistent within osmo-bts-trx itself, as
under certain conditions the common code in l1sap will override
the UL payload from the BTS model and emit its own form of BFI
instead.
Fix all of the above by removing trx model-specific BFI formats
for all codecs, and let l1sap handle all BFIs.
Related: OS#6033
Change-Id: I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
The paging interface towards the PCU has a confusing API. In fact what
the PCU does when it wants to page or do an immediate assignment is
sending a ready formatted MAC block to the BTS. The BTS then puts this
MAC block in the paging queue and then eventually it justs sends it
without looking at the contents. For the code in paging.c it is not
imortant if the MAC block is an immediate assignment, it only cares if
the paging record contains a MAC block or paging parameters.
Related: OS#5927
Change-Id: Ifab37fdedaba98b160718113767e4ef6ee7d16ad
In all OsmoBTS models in FR and EFR speech modes, as the UL traffic
frame stream is passed from the PHY to l1sap and ultimately to RTP
output, all passed frames are checked for SID. The Boolean result
of this SID check is used in two ways:
* RFC 3551 instructs that the Marker bit in the RTP header SHOULD be
set in the first packet of a talkspurt after a period of silence
suppression. OsmoBTS implements this recommendation by setting
the Marker bit in the first RTP-transmitted non-SID UL packet
that was preceded by SID.
* In osmo-bts-trx only, this same SID check serves a second purpose:
handling of BFI conditions depends on whether or not the last received
good traffic frame was a SID. If a BFI condition is received after
a non-SID traffic frame, the ECU is invoked, and if this ECU fails
or when libosmocodec does not provide an ECU for the codec in use,
a special FR (EFR) BFI frame of 260 (244) zero bits is emitted.
Both the ECU call and the peculiar form of BFI are skipped when the
last received good traffic frame was a SID.
For both of the above purposes, in all BTS models, change the SID check
from osmo_{fr,efr}_check_sid() to osmo_{fr,efr}_is_any_sid(). The
effect of this change is that "what counts as a SID" for the just-listed
purposes changes from recognizing only perfectly uncorrupted SID frames
without any bit errors to recognizing all frames which the rules of
GSM 06.31 (FR) or 06.81 (EFR) classify as either valid or invalid SID.
Change-Id: I5c24b379deda8ae551f9924d10770da50e6acbbd
Commit 32682c63f6 fixed EFR SID handling in osmo-bts-sysmo,
but that fix was never propagated into osmo-bts-{lc15,oc2g} versions,
which are essentially copies of osmo-bts-sysmo. Fix that oversight.
Change-Id: I509c1ea374e640d819952d58592b12fa884ad9d8
Those network elements which receive a stream of codec frames that
may come from the uplink of GSM call A and which are responsible
for preparing the frame stream for the downlink of GSM call B
(such as OsmoBTS receiving RTP and feeding DL to its PHY) must be
prepared for the possibility that their incoming frame stream may
contain corrupted SID frames, presumably from bit errors on radio
link A. Per the rules of section 6.1.1 of GSM 06.31 for FR and
GSM 06.81 for EFR, SID frames with just one errored bit are still
to be accepted as valid, whereas frames with more corrupted bits
which are still recognizable as SID are classified as invalid SID.
In the case of a TrFO call, the entity switching from leg A UL to
leg B DL is responsible for *not* transmitting invalid SID frames
on the destination leg (they should be treated like BFIs), and any
deemed-valid SID frames that are forwarded should be preened,
correcting that one bit error they may exhibit. Implement this
functionality in OsmoBTS.
Change-Id: I89df2f12c49dd5378667cf149d19bde654f80134
When the NM_EV_RX_OPSTART event is received, it will call bts model
specific function bts_model_opstart(), which is responisble for
answering back with NM_EV_OPSTART_ACK or NM_EV_OPSTART_NACK.
Since that answer could be done sequentially in same callback code path,
we could end up twice at the end of the st_op_disabled_offline()
function checking for statechg (due to reentring that function).
As a result, one can see the following message appear during OML
bring up:
nm_bb_transc_fsm.c:185 NM_BBTRANSC_OP(bts0-trx0){ENABLED}: transition to state ENABLED not permitted!
Fix the issue by avoiding ending up at the end of the function in code
paths which should not be triggering any change.
The case of bbtransc is a bit different than that of rcarrier for
NM_EV_RX_SETATTR, since the former really doesn't receive any such
message from the BSC yet, so if we checked for that one before
continuing, it would never go on.
Change-Id: I5184a33dd8da9244e8aacf3ab8bb8930f732a136
The info indication on pcu_sock cann only support a limited but
sufficient number of TRXs, when we detect that we overflow the maxiumum
number of TRXs, then break and do not continue.
(this is more or less a cosmetic problem)
Change-Id: If4d7eecaded22f86750283f7aa13072064724537
The function rtppayload_is_valid() is called from the receiving RTP code
path. Lets use the word "forwarding" instead of "sending" to avoid the
impression something is sent (like sending RTP packets to the outside
world)
Change-Id: Ie7fcc53dea462b0d575b0c9ca73ba7507289eefe
This code has been there since first octphy support was added.
New gcc 13.1.1 is catching this and reporting compilation errors:
"""
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘ts_connect_as’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: note: ‘oc’ was declared here
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘bts_model_ts_disconnect’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: note: ‘oc’ was declared here
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
"""
Change-Id: I0da7d3a94e9eba15b8d3d3d995bba532170d9df7
osmo-bts-trx uses the RFC5993 RTP payload format, so when handling the
RTP payload use GSM_HR_BYTES_RTP_RFC5993, instead of GSM_HR_BYTES + 1
Depends: libosmocore.git I125ef9cdab98c073971841c175b1a7dcd927f9c2
Related: OS#5688
Change-Id: I54dd3adab88e2262913f7b1e89340a0246c88a8a
We should not maintain BCCH carrier power reduction mode if we loose
connection to the BSC. When entering NM_BTS_ST_OP_DISABLED_OFFLINE,
reset the related state fields if it was enabled.
Change-Id: I34468e3fccc490f48e30b159b63308a395b65fa9
Related: SYS#6435
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (fixes OS#5967
together with change I37e6b23ed95260a8188910cf9754faffcba519c5)
Change-Id: If734ea2c8cae4c1f99b02520dffa4e3862a67745
Related: OS#5961, OS#5967
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (part of fix
for OS#5967)
Change-Id: I37e6b23ed95260a8188910cf9754faffcba519c5
Related: OS#5961, OS#5967
The following output can be seen when doing 'show bts' in the VTY:
BTS model specific (internal) flags:
001 Measurement and Payload data combined
003 unknown 0x8
Fix this by adding the missing values to the value-string array.
Change-Id: I83e5065f9f80b4f81e9767f184c8dc027883025a
Fixes: 0277cddab "sysmo,oc2g,lc15: Make RadioChannel MO depend on RadioCarrier MO"
Fixes: ee5eb6169 "l1sap: check if BTS model supports interference reporting"
In change 8e04613e I overlooked that osmo-bts-virtual is re-using the
scheduler of osmo-bts-trx and forgot to update its OML logic. As a
result, osmo-bts-virtual is broken and does not transmit anything on
the broadcast channels.
Change-Id: I2276f7e5e4042e56ddf1fd1642c917dba0005ac4
Fixes: 8e04613e "osmo-bts-trx: properly activate [CBCH/]BCCH/CCCH"
Related: OS#6001, OS#1572
Better wait until the DSP is reset and all the information is retrieved
before telling upper layers that the phy is ready. Keep it in CONNECTING
state meanwhile.
Change-Id: Ifdc791336fb8efd42f4428893f687093085af129
The fields used to fill in pinst->version are set when info_compl_cb()
is called, which happens asynchronously and hence later than when in
bts_model_phy_link_open().
Hence, copying the values when in bts_model_phy_link_open()
(l1if_open()) makes no sense at all.
Fill in pinst->version in info_compl_cb(), just when the layer receives
the required information.
Related: OS#5978
Change-Id: Ica53a5d852214b24de7f75b08ad7e595ce5236ee
If the TRX_NR had no matching TRX it would access a NULL pointer trx
after failing to resolve it.
This commit refactors the code path to only require the trx pointer at
the very end, and NACKs the message if TRX fails to be resolved.
Change-Id: If27639ae1727fc5232e1a964a1b29f50c8805d80
All the other objects already use that one; there's no need to have a
specific one for the NM Channel FSM.
Change-Id: Ic5fd37367b500c75a0a53b1d868ba2aed3edef1b
This way the data model in TS 12.21 (Figure 1) is followed, where
there's a BTS Site Manager containing one or more BTS. In our case we
only support 1 BTS (cell) so far.
Change-Id: Ideb0d458ec631008223f861cf8b46d09524a1a21
Related: OS#5994
As it has come up during code review of Change-ID
I214af0448652a9f321ccbab77977b67663ba28f9 introducing LOGPLCNF, my
approach to the strict preserval of argument order (lchan first from
LOGPLCHAN and fn *after* loglevel from LOGPFN) was considered
sub-optimal.
I used the following spatch rule to clean this up:
@@
expression lc, ss, logl, fn;
expression list trailer;
@@
-LOGPLCFN(lc, ss, logl, fn, trailer);
+LOGPLCFN(lc, fn, ss, logl, trailer);
Change-Id: Iba4a8416545673d03cb057e4855f8b1ecae3e1ec
Add the BTS object to the BTS list as the first thing after it is created,
this way it's always attached and hence simply always detach it during
object free.
Change-Id: Ica4fe2a4be0c85b10702011e978be03bf970b0c8
Move it together with the other similar objects like gprs_nse and
gprs_cell.
Move the "mo" field to the start of the struct, similar to the other
types.
Change-Id: I5dc020a6bab8c94ab831b6ca506bc5cb681d07a3
Octet 2 should contain the address of the GPRS cell in the GPRS NSE
object. Since there's 1 GPRS Cell per BTS and we have only 1 BTS in
osmo-bts, then this address should be 0.
Otherwise, osmo-bts answers sometimes using (0x00, 0xff,0xff) instead of
requested (0x00, 0x00, 0xff), for instance when ACKing an Admin Unlock.
This is kinda still fine since value 0xff has the meaning of "all"
addresses, and that means the only one available.
Still, it's not the proper way to identify the object, so this patch
fixes it.
Change-Id: I2ea05778f5b5ac335c75f3958324664553da7f0d
This way we have further control on how to handle the OPSTART messages
received. For instance, NACK them if the NM object FSMs are not at the
expected correct state.
Related: OS#5992
Change-Id: I5df0bfb4cc812c11c7a00a8ffa882ae1915d562f
The param is usually called obj_class, but here it is called kind.
In any case, change the param to pass the related struct gsm_abis_mo
(which still contains mo->obj_class), similar to what's done in other
bts_model functions such as bts_model_opstart().
Change-Id: Ife2e98a791455d5f7e7052356d559af2f1d4d185
This way we simplify the common lower level interface. It can be added
in the future again if it is really required at any point to pass/use
specific TLV values in the device-specific code.
Change-Id: I64c6c6834e277b1d75a97d6f408e7e1b7ca85832
Simply return error codes from lower layer implementations, and do
the OML handling in the common NM TS 12.21 FSMs.
As a result, we simplify the logic in the lower layers.
Change-Id: I281c07bb5ad88ee03542f092141cebe036d10aee
We have LOGPLCHAN and LOGPGT, but not a combined version for logging
both the lchan and the gsm_time. Let's resolve this.
Log messages without indicating the lchan name are pretty useless if you
have multiple concurrently active lchans...
Change-Id: I4bf3363f92acdf67d8e7333e30ac2209e31cb287
This way we have further control on how to handle the SetAttr meessages
received. For instance, NACK them if the NM object FSMs are not at the expected
correct state.
The originating msgs are now kept owned and freed by the OML layer
(oml.c), and the NM FSMs only uses them and create new OML msgb when
answering with ACK/NACK.
Related: OS#5992
Change-Id: Id68868e25bbf96227ab6459fcd3c9181852ed28e
Calls to bts_model_apply_oml() are done only for BTS, RCARRIER and
RCHANNEL NM Objects in their respective Rx code paths (and they will
be moved to respective FSMs in follow up patches). This function is
never called with any of the GPRS NM objects.
These NM Objectes have the NM_MT_IPACC_SET_ATTR msg ACKED/NACKED in its
own path:
oml_ipa_set_attr()
rc = oml_ipa_mo_set_attr()
return oml_fom_ack_nack(msg, rc);
Change-Id: I1a0d38a122f50ffe749ebc4f1cc11235ca516586
The function repeat_last_sid() is implemented in the common part,
but is only used by osmo-bts-{lc15,oc2g,sysmo} models. These BTS
models call this function when they are looking to see if a
previously cached SID frame needs to retransmitted on the DL
because it is that time according to the SACCH multiframe.
Out of non-AMR codecs, this function previously supported only
FR1 and HR1, but failed to support EFR. Fix that omission.
Change-Id: Iebcd28e65af889254740757eed9c579392eb1c33
Automatic generation of a header file using a C program built during
build of osmo-bts creates several problems when cross-compiling.
The generated header file is only 59 lines long, so let's have it
generated in order to avoid having to call the helper program every
time.
A Makefile target is added to easily regenerate the file manually in
case it's needed:
make -C contrib/ber/ update_codec_bit_class_h
Fixes: acf0f0f0bb
Change-Id: I97efdb4ee00537fcae191b4267d0211d582ef372
There was a surprising number of explicit gsm_lchan_name() calls
from within log message code. Let's avoid that whenever possible and
use a LOGPLCHAN() or related macro.
Change-Id: If4f4f555f5ca61dfa624b298805f5375efc0b137
When FACCH stealing occurs and sysmoBTS L1 delivers GsmL1_Sapi_FacchF
instead of GsmL1_Sapi_TchF, that 20 ms unit still needs to be
accounted for in the RTP timestamp cadence, and if we run with
rtp continuous-streaming enabled, then an actual BFI packet needs
to be emitted. The original code failed to do either; the present
change implements correct behavior for TCH/F.
The present patch only covers the case of TCH/F; handling of TCH/H
is left as a FIXME for other/later developers.
Related: OS#5974
Change-Id: I39d15faade28fb7d670493a99a0e0bdb654e2a4a
The check for (tch_ind->lqual_cb >= bts->min_qual_norm) in
l1sap_tch_ind() has the intent of suppressing valid-seeming
speech frame output from lower layers when the link quality is
too low; this check is particularly important for FR1 codec
where the intrinsic validity check is only a 3-bit CRC which has
1/8 probability of indicating "correct" when decoding radio noise
during DTXu silence.
However, this check is effectively defeated in the current
implementation of rtp continuous-streaming: the RTP packet being
output is the presumed-bogus speech frame from lower layers,
rather than the intended zero-length payload. Fix this bug.
Related: OS#5975
Change-Id: Icee0f57be289a0592a0197469432a012d15f224c
This implements RTP based GSM BER testing for osmo-bts, implementing
ideas described in https://osmocom.org/projects/osmobts/wiki/BER_Testing
In short: The command transmits a PRBS sequence encapsulated in RTP
frames, which are sent to the BTS, which transmits that data in the
(unimpaired) downlink. The mobile station receives the data and is
instructed to loop it back in the (possibly impaired) uplink. The BTS
receives that uplink, puts in in RTP frames which end up being received
back by this very tool. By correlating the received RTP with the PRBS
sequence, this tool can compute the BER (Bit Error Rate) of the
(possibly impaired) uplink. Doing this with different RF channel model
simulators in the uplink allows to establish BER at different levels and
channel conditions.
Original code by Sylvain Munaut extended with some comments and Automake
integration by Harald Welte.
Change-Id: I1cffa0ae959e29ec61775b13185fd1057ed7485a
oml.c: In function ‘bts_model_apply_oml’:
oml.c:1814:17: error: variable ‘cell_size’ set but not used [-Werror=unused-but-set-variable]
1814 | uint8_t cell_size;
| ^~~~~~~~~
Change-Id: I0bf1542f613f613d03609d50836137ff440401af
This default phase of the Codec Mode Indication in downlink direction is
called "odd", which is defined by starting with CMC in every 26
multiframe.
At call set-up, after every successful handover and after a channel mode
modify, the default phase (odd) shall be used in downlink direction.
During a call, the phase of Codec Mode Indication may be changed in
downlink by using a RATSCCH message.
As we don't implement RATSCCH, odd is always correct.
Change-Id: Ia64767fbfdc3fb067d72dbf5eabb1d84e3868ce5
oml.c: In function ‘bts_model_opstart’:
oml.c:1883:32: warning: variable ‘ts’ set but not used [-Wunused-but-set-variable]
1883 | struct gsm_bts_trx_ts *ts;
| ^~
Change-Id: Ifd5552f2dd56f4f9bf4c17d25b741f694f4f2168
l1_if.c: In function ‘activate_rf_compl_cb’:
l1_if.c:1280:17: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
1280 | if (bts_lc15->led_ctrl_mode == LC15_LED_CONTROL_BTS)
| ^~
In file included from ../../include/osmo-bts/dtx_dl_amr_fsm.h:3,
from ../../include/osmo-bts/msg_utils.h:8,
from l1_if.c:55:
l1_if.c:1282:25: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
1282 | osmo_fsm_inst_dispatch(trx->mo.fi, NM_EV_DISABLE, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~
Change-Id: I00ae3faf0f85fecf6e15e71dff071165725e547c
Our linter would complain about this these days:
__func__ should be used instead of gcc specific __FUNCTION__
Change-Id: I80bf6d0a89ce6454ae063759d6088a28b04670c0
In some environments it is highly desirable for the RTP stream
coming from each GSM call UL on a BTS to be fully continuous,
without any gaps, with _some_ RTP packet emitted every 20 ms,
even if there is no speech or SID frame to be sent in that frame
time window. The present change adds an rtp continuous-streaming
vty option which, when enabled, causes the BTS to emit RTP packets
with a zero-length payload, instead of producing gaps in the RTP
stream, when it has nothing else to send.
Related: OS#5975
Change-Id: Ic0e2edf2ed90ba0ac6bee5e7d9629bf0255e256d
Handling of SID in EFR mode was broken in osmo-bts-sysmo.
l1_to_rtppayload_efr(), the function for UL Rx, was using completely
bogus logic (passing bits in ETSI TS 101 318 EFR format to an AMR
decoding function), whereas l1if_tch_encode(), the function for
DL Tx, had missing SID logic for EFR while supporting SID detection
for all other codecs. The fix is to use the new osmo_efr_check_sid()
function in libosmocodec.
Change-Id: Ia56c1bb7432968685110456961d24a907b0a201f
The TCH/F Rx code in osmo-bts-trx uses osmo_fr_check_sid() to detect
when the MS sends SID, and passes the flag to lchan_set_marker().
However, equivalent logic was missing for EFR, as until recently
there was no EFR SID check function in libosmocodec. Now that
we have osmo_efr_check_sid(), use it.
Change-Id: Ib043e00dbf92145c2a6c32f6365517244472a922
So far we only printed it during later modification. Let's print
it also during initial activation of a logical channel.
Change-Id: I6982a52905e4719e2e9c40630252ffef2ff9fbed
When we receive a SID_FIRST_P1 frame from the PHY (during AMR/HR DTXu),
we must generate a SID frame on the RTP side.
The existing code
* ignored that the Amr_SidFirstP1 PHYIF message actually contains the
RTP payload
* manually generated the same content using osmo_amr_rtp_enc()
* forgot to prefix that with the AMR CMR+TOC
* in the end, sent a completely broken (too short) AMR SID frame over RTP
Let's fix this by simply using the 7-byte RTP payload with CMR+TOC that
the PHY is providing to us.
Change-Id: I90479efcc002d497648a71e73847af54e6208358
Related: OS#5944
So far, we've had LOGPLCHAN() and LOGPFN(). This resulted in a number
of log lines containing frame numbers *not* containing the lchan
context, which makes it difficult to deterine which of potentially many
concurrently active lchans is logging.
Let's introduce LOGPLCFN() for a FN-extended version of LOGPLCHAN(),
and convert all callers that have the related context.
Change-Id: I214af0448652a9f321ccbab77977b67663ba28f9
We're printing DEBUG messages for all other DTX frames, but not for
ONSET. This made me think that we never received any ONSET frames
when looking at log output.
Let's add ONSET for completeness.
Related: OS#5944
Change-Id: I9a1511d9929444cef96388492d907e8f3a082311
ph_tch_req() is a recursive function and conditionally calls itself at
the very bottom. The recursive call happens iff all of the following
conditions are met:
* DTXd is enabled,
* AMR codec is in use,
* DTX DL AMR FSM state is recursive.
The problem is that ph_tch_req() may pull sizeof(*lsap) from the given
msgb twice: during the initial and the recursive calls. The second
attempt to pull sizeof(*lsap) causes the process to abort, because
the remaining room is less than it's attempting to pull.
AFAICT, doing msgb_pull() is not really necessary, given that
l1sap_tch_rts_ind() thankfully does set msg->l2h before pushing
the lsap header in front of the actual frame.
Update osmo-bts-sysmo and its copy-pasted siblings, which are likely
affected too, except osmo-bts-octphy which does not do the recursion.
Change-Id: Ib349b74a9e4bd48c902286f872d3b0e9a068256c
Related: OS#5925
It makes no sense to push interference meas results for those TRX since
they are disabled, unused and hence won't be reported in RSL RF Res Ind.
Related: SYS#6370
Change-Id: Ie3fd80970585cb30808b0644568dbc8936a57721
The timeslot carrying BCCH/CCCH on C0 is a bit special in a way that
it's being activated implicitly - there is no explicit RSL CHANnel
ACTIVation for that. This is why we have TRX_CHAN_FLAG_AUTO_ACTIVE,
which marks sub-channels of BCCH/CCCH in the trx_chan_desc[].
The upcoming patch changes the burst buffer allocation strategy, so
that the memory is allocated on channel activation and then free()d
on channel release. This patch facilitates that by making the
activation/deactivation logic consistent for all sub-channels.
Change-Id: Id0c70d6a2b777a5117c85149bfa1b3a997299d1d
Related: OS#1572
The header file <osmocom/gprs/protocol/gsm_04_60.h> was recently
deprecated and moved to <osmocom/gsm/protocol/gsm_44_060.h>, so
it's now part of libosmogsn and depending libosmogb is not needed.
Change-Id: I823de7ebac2fe5dfddb88d533f1a9419f4a605db
Related: libosmocore.git I70cc21bf25a7081070738abacb409ed19094c3b2
Related: OS#5312
This change fixes a problem that prevents osmo-bts-virtual from
starting when dynamic (ipa/osmo) timeslots are in use.
Change-Id: I5db5b7dd6a8e84cf9a0d84f04a650c2ed8a4e368
The code in that function is pretty rotten:
* osmo_fd_write_disable() is called for each message in the queue,
there's no need for that. Let's simply call it at the end if the queue
is empty.
* Asserting for obvious stuff like dequeue returning the first entry in
the list.
* Having error code path for empty message: That shouldn't happen, abort
immediately.
With all thse changes, the function is way simpler, easy to read and
more efficient.
Change-Id: I7ffff98cd8cdf2041bff486c3fde6f16365028d5
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I06d3d5ab1dd21400a72f76eecc508886617ef4c6
These two messages indicate that no ACK/NACK message is going to be
sent to the BSC because activation/deactivation was requested by the
PCU. This is absolutely normal and requires no attention from the
user/operator, so better use LOGL_INFO.
Change-Id: I6eaf3a6c07fb30b31c045729c935c8ad6735e5c8
Parse the RTP CSD Format and reply with NACK if the mode is not
RSL_IPAC_RTP_CSD_TRAU_BTS, which is the only one we plan to implement
for now.
Related: OS#4393
Change-Id: Ibfc7811387df5224682d7e6a313d38648d3d8c48
Add documentation for rsl_ipac_rtp_csd_format_d/_ir from
libosmocore.git, include/osmocom/gsm/protocol/gsm_08_58.h and
wireshark.git, epan/dissectors/packet-rsl.c.
Related: OS#4393
Change-Id: Ic8f40076698f2b341cc0096fd96ba2051a41f077
Forwarding of PDCH related data over multicast works for me.
Without these features osmo-bsc would reject the OML connection
if it's configured with [E]GPRS enabled.
Change-Id: I5e13c153805c56904e51d222007228e1c2872c88
Related: OS#5500
osmo-pcu requires to get DATA.ind for all FN/TS it manages in order to
tick its internal FN clock and trigger timeouts. Without this, some
events are ticked in a delay fashion when osmo-pcu detects FN jumps.
Change-Id: I8f1856dd9061c1bfca8b15be30df7a51760231b0
Differentiate in each TRX between being provisioned (configuration available) and being provisioned *plus enabled*.
TRX0 waits for all other TRX to be ready before sending POWERON, since
all TRX need to have been minimally configured over TRXC before POWERON
is called. This "ready" state though, doesn't necessarily mean the
TRX!=0 are enabled (aka NM Enabled and rf_locked=0). With them being
configured it es enough to start the whole PHY.
With the old logic, given any TRX was rf_locked=1 at startup, the PHY
would not become UP because it the TRX_PROV FSM was waiting for OPSTART
to arrive on all TRX, which wouldn't happen on TRX that had rf_locked=1.
So in summary, the desired requirements to start the PHY are (in any
order):
1- Wait all TRX are configured
2- Wait for TRX0 OPSTART
Related: SYS#6370
Change-Id: Ie4836f5721ce8227a63c267730aeb17228994214
Having a common body for PRIM_INFO_{ACTIVATE,DEACTIVATE,MODIFY},
but then branching using if-statements is a bit confusing.
Change-Id: I915c8a541249249e3c0b1f2eda4535e7c52db79f
Related: OS#1572
The variable rc holds the return code of accept(), which returns a file
descriptor on success. So lets call the variable "fd" to make this
clear.
Change-Id: Ibc359d941786b1d1d52b356e239a76a090b52c1f
A request to send an Immediate Assignment over the PCH (not AGCH)
is always coming from the PCU. It's used for DL TBF assignment.
Change-Id: If4b0aa01532ab65b96201ff8829e724c67df6993
Premature activation of virtual scheduler in bts_model_phy_link_open()
leads to segfault in vbts_sched_start(). Fix this by moving scheduler
activation to bts_model_oml_estab()
Change-Id: I116c2548dd4d05df90c16e81fa2e85ed6027a2e1
Fix condition `block_nr == 4`, which was never reached, by effectively
replacing
- `4` by `msg->num_segs`, so we truly check if the current
block is the last of this message
- the index `block_nr` (which starts at zero) by `block_nr + 1`,
so it is comparable to `msg->num_segs`
Related: OS#5354
Change-Id: I3dc116d6c16c80b31712b2a969f0b2a6998b03f0
Looks like this is not needed, so make the jenkins build work without
installing dahdi-source.
Related: OS#5863
Change-Id: I61c483983a4793e0429bb37804dee0a128125daf
The VTY command is "local-port", but write-config would write "port"
instead, which would fail when re-reading the config file.
Realted: SYS#6237
Change-Id: Id08530b626b0e69c3b3bb9d8bb9e16080a73e74d
Both power_ramp_start() and power_ramp_force() are now small macros
around _power_ramp_start()
The new behavior is:
* ramp down power when stopping bts through Ctrl-C
* the other shutdown causes skip power ramping
This will cause the bts to reconnect faster when the oml link is
dropped and power ramping is enabled.
Change-Id: Ida1d7bbf094958b9142af306dbf84206729a609e
Related: SYS#6237
There is no reason why they should have different initial
states. Keep it consistent with the other MOs.
Change-Id: I9fd744ec79da9fc26d3ebe9857b2b0bbd5fcd1ff
This reverts commit c96d34f828.
Reason for revert: This breaks ramping up power since the power ramp logic still assumes the output is full power.
Change-Id: I47a16a4b3ba02d74473569c0f4350a41fc12a464
For the other shutdown causes power ramping doesn't make sense. Instead
shutdown quickly so we can reconnect faster
Change-Id: I71c46478b8f3b236dba3e959fc75e58c0409517f
Related: SYS#6237
The array of trx in gsm_pcu_if_info_ind can hold trx 8 items. Lets use a
define constant to specify the size of that array.
Change-Id: I5fdd5b9e59865fabd0340650ecb347d52208ebe9
The pointer variable l1sap is only used to determine the size of the
related struct but for nothing else. We can use the struct name in
sizeof also directly and get rid of it.
Change-Id: I93abdce1dec60d53ddceb1fce6e9e7451ba6283a
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Related: SYS#6161
Change-Id: I72803fb172accbabfc81923572890f8ecb06cefd
The scheduler is now using the lookup tables instead of these
functions. The only part using them is the AMR unit test.
Change-Id: I1a9c80dd12252e7befe9c9bc8e8f7ee8648b5465
The number of NSVCs is fixed but lets not use magic numbers to define
the sizes of the arrays that hold the config values. In osmo-pcu there
is already a define constant, so lets use a define here as well.
Change-Id: If7fa44abb86c18900110d7ee81fe6140c8c4635b
Some osmo-bts varieties have a method to make an immediate change to
TX power from the vty. In osmo-bts-trx there does not seem to be any
way, so lets start the power ramp loop when the parameter
osmotrx tx-attenution is changed on a running TRX.
Change-Id: I1fa5e8130202fb509593db4132863b762b0f40b7
The parameter l3_len in rsl_tx_meas_res() is defined as int, even though
it can't be negative. Lets use unsigned int for l3_len.
Change-Id: I99068a36e74a557000f406154dce32300615086c
We request the length using msgb_l2len() in two locations where whe
cannot be sure that l2h is populated. Lets check this first.
Change-Id: Ie13d0724f183ff240714dcdbd24e5a21b4276bfe
Related: OS#5645
The function lchan_meas_handle_sacch() calls msgb_l3len without checking
if l3h is even populated. Lets add a check to be sure.
Change-Id: Ie5a9fe1ba880e68edb74f5f4ca559ac191330d4f
The PCU may poll the MS requesting an ACKnowledgment message to be
sent in form of four Access Bursts instead of Normal Bursts. The
BTS has no prior knowledge of the Uplink burst type, so a new MTS
value was specified in order to prevent the BTS from trying to
decode Access Bursts as a PDTCH block.
This patch implements parsing of the new MTS value 0b0110.
Signalling RACH.ind to the PCU is to be implemented.
Change-Id: I0fbb63006797e6be386d1f76ed97fff098c036fc
Related: OS#4006, SYS#4794
Checking if (bi->chan != TRXC_RACH) is not enough to detect HANDOVER
ACCESS. Receiving this message is only possible on CS channels.
Change-Id: Ice1674fd4fed8c54d605ff19d568f6e46b4c5783
Lchans which are marked as non-connected have not yet received
information about its remote peer, hence they may not have some fields
available yet. Let's skip them to avoid accessing such fields
(lchan->abis_ip.osmux.in).
Related: SYS#5987
Change-Id: Id53822c4a0486b0090df2db3d185e047d14fc90a
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#598
Change-Id: I102047685b9b9f4cba43970945f955c4fe9c4c95
This way we have no more access to internal osmux structures.
If those counters are needed in the future they can be counted by
osmo-bts by means of adding rate counters to the caller of
osmux_xfrm_input() and deliver_cb.
Change-Id: Ib952437ea3aa2770c96bddb667491e7675a6a06e
Otherwise some shared variables used by both Osmux and RTP was left set,
like connect_ip and connect_port, and next time the lchan was selected,
those were already configured even if they didn't come in IPAC CRCX.
This is specially bad if the channel was reused to set up an Osmux call,
since the osmux code path relied on those fields being properly reset
until set by IPAC CRCX.
Change-Id: I414bd0bc801451357bb45b89197a95e51b7c97f1
when something fails in osmo-bts during startup and it goes into SHUTDOWN state,
it is desirable to close new RSL links (sockets) which are in progress to connect,
while it waits for a while to complete shutdown (power ramping down, etc.).
This way we don't end up with new interactions and new state against a BSC if we
are shutting down.
The new libosmo-abis API is used since the higher layer struct e1inp_sign_link assigned
to each struct gsm_bts_trx is not provided to the osmo-bts code layer by libosmo-abis API
until the TCP+IPA handshake in the socket becomes fully established (sign_link_up()
callback).
Depends: libosmo-abis.git Ia6418321f3b6f1f7274efd414625a4b10a09a362
Change-Id: I599d074f51f490b43c9a89b105d1823391926947
It's not immediately obvious what numeric values mean for CPU scheduling policy.
Let's document this and add doc reference.
Related: OS#4107
Change-Id: Ib047762a336851e6205d77c83068a99d8a868e8b
Previously osmo-bts created /var/run/osmo-bts.pid which
isn't used by anything and makes it hard to run as non-root
user. Let's get rid of this pre-systemd relic.
Related: OS#4107
Change-Id: I86bcaedbc8cb1297476ad741eaa45585fea3c380
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I4b7bcd441e5da81c4c5267715675041171a1ce1e
This helps understand the origin/purpose of those 2 bytes and
what's contained in them.
Related: SYS#5987
Change-Id: I607fdf6d627242e010fba35be1b9b0ffde820d08
This library will be used soon when adding Osmux support to osmo-bts.
Furthermore, it nice to have it available to make use of other general
interfaces to create connections, primitives, RTP and AMR related
functionalities, etc.
Related: SYS#5987
Change-Id: I49db4de715065c083e1249cbeae6298d6868e229
The PRIM_INFO_MODIFY is sent on receipt of the RSL MODE MODIFY message,
which may optionally contain new ciphering parameters. Before this
patch, osmo-bts-trx would ignore the new parameters and continue using
the old ciphering key/algorithm.
* Modify l1if_set_ciphering() to allow updating ciphering params.
* Call l1if_set_ciphering() when handling PRIM_INFO_MODIFY.
This problem was uncovered by BTS_Tests.TC_rsl_modify_encr, which has
been failing ever since it was introduced [1]. This patch makes it pass.
Change-Id: I2278703b487374c0de4cfc42b22e70aaf6548589
Related: [1] I4cbea499bb6a331d314e6573548a4540945208b5 osmo-ttcn3-hacks.git
Related: OS#3750
It will be used too by osmux code present in another file. This is a
preparation commit to simplify the one adding osmux support.
Change-Id: Ie7fa57bb04db9ad9b03971467e12ee7b8e4c190a
The function is long/complex enough, so having one extra struct in_addr
declared the function top only used in one specific small path to print
the variable is unnecesary.
Let's move it to the conditional path where it is used to print the
ip address.
Change-Id: I4c16bbca6a6779537517b6b196828b47eddaa516
There's no need to maintain a duplicate msgb_queue_flush(), which
returns the amount of freed messages (feature not used at all by the
callers).
Change-Id: I9841e18ca0b7b852130bbb02a510e43a3b3fd93f
The queue_limit_to method iterates the entire list of messages every
time a new message is added. Let's use msgb_{enqueue,dequeue}_count()
APIs to do that in constant time. It is true that since the queue is
limited to 1, there's usually at most 1 item in the queue so it's not a
real problem. However, when we add Osmux in the future, we may need to
tweak the amount of messages which can be in the list, due to Osmux
batching mechansim which may be more bursty sometimes.
In any case, this change doesn't make things worse for sure.
The patch also takes the chance to group the queue_limit_to + enqueue
into one function to avoid having the code spread several times.
Change-Id: I61818a3bb521c27bd21a8b6fa70581d27638ec9b
Make them more easy to read and edit by splitting to one element per
line when several elements are present.
Change-Id: I24ecfa1167b806dcb3a5a0c00343299df842a78b
The logic responsible for enabling and disabling the loop appears
to be broken: during my experiments trx_loop_amr_set() was never
called with loop=1. It's not clear what's the motivation behind
this breaker, so I propose to rip it out for now. This patch
finally makes the loop work (confirmed with a TEMS phone).
Change-Id: I09b649973d4269c4082a4fafa493c37825f95a9c
Related: SYS#5917, OS#4984
This reverts commit 1f9fbd8816, which
was a workaround rather than a proper fix. The root problem has
been fixed in libosmocoding [1], so ~50% BER is not the case for
AFS_SID_UPDATE frames anymore.
Related: I813081a4c0865958eee2496fe251ae17235ac842 (libosmocore.git)
Change-Id: Iebe139632daf1d1f72e39fe9d1497059f68625b9
We have two similar values in enum gsm0503_amr_dtx_frames:
* AFS_SID_UPDATE - precursor of SID UPDATE,
* AFS_SID_UPDATE_CN - the actual SID UPDATE.
The former is internally used by libosmocoding to mark the current
frame as a precursor of the actual SID UPDATE frame - the later.
+---+---+---+---+---+---+---+---+
| _ | _ | _ | _ | a | b | c | d | AFS_SID_UPDATE
+---+---+---+---+---+---+---+---+
| a | b | c | d | _ | _ | _ | _ | AFS_SID_UPDATE_CN
+---+---+---+---+---+---+---+---+
^
|
| We're here.
Do not treat the precursor frames as a SUB frames, as they contain
no information (rc=-1) and usually have *expected* BER ~50%. This
fixes unexpected RXQUAL-SUB > 0 in the Uplink measurements during DTX.
Change-Id: I46f32bbbcb6284615d05b8703945c5ca4da55b92
Related: SYS#5853
3GPP TS 45.008, section 8.3 defines active TDMA frame subsets for
TCH channels, which shall always be transmitted even during the
silence periods in DTX mode of operation. Each frame number
listed in this section corresponds to a single burst.
The Uplink measurements always contain TDMA FN of the *first* burst
of a block, so it does not make sense to match the given FN against
all FNs in the respective subset. Instead, we should match only
specific FNs in accordance with the block mapping rules defined in
3GPP TS 45.002, section 7, table 1.
In the active subset for TCH/F there is only one *complete* block
starting at FN=52. Incomplete blocks {52, 53, 54, 55} and {56, 57,
58, 59} contain only 50% of the useful bits (partial SID) and thus
~50% BER, so we don't treat them as SUB.
In the active subsets for TCH/H there are two *complete* blocks
for each sub-slot. Their respective first FNs can be efficiently
defined in a lookup table (see ts45008_dtx_tchh_fn_map[]). Note
that we can use a single lookup table for both sub-slots of TCH/H
because their TDMA FNs do not overlap.
This patch fixes unexpected SUB-RxQual values > 0 on TCH channels
with DTXu enabled and other than AMR (HR, FR, EFR) codec in use.
Change-Id: I8cc3a755a8ad4dc564439aab2298c1e97ac0592d
Related: SYS#5853
SACCH detection can be simplified by checking the RSL Link ID in
process_l1sap_meas_data(). This eliminates the need to lookup
the multiframe position by calling trx_sched_is_sacch_fn(), which
definitely takes more CPU time than just L1SAP_IS_LINK_SACCH().
Calling trx_sched_is_sacch_fn() is still required for BTS models
reporting the measurements via PRIM_MPH_INFO (legacy way),
separately from the related Uplink blocks.
This patch can be summarized as follows:
* detect SACCH and set .is_sub=1 in process_l1sap_meas_data();
** for PRIM_MPH_INFO use trx_sched_is_sacch_fn();
** for PRIM_PH_DATA use L1SAP_IS_LINK_SACCH();
* do not call trx_sched_is_sacch_fn() from ts45008_83_is_sub();
* modify the unit test - test_ts45008_83_is_sub_single();
** remove test_ts45008_83_is_sub_is_sacch().
Change-Id: I507e96ee34ac0f8b7a2a6f16a8c7f92bc467df60
Related: SYS#5853
* Print unexpected TDMA FNs, each on a separate new line.
* Do not abort() on mismatch, keep running.
Change-Id: I32c104b139f32a39c8347de19de6ad7caec811de
Related: SYS#5853
Attempting to detect missing Uplink frames in the *Downlink* path
is an ugly hack, that was needed before we had proper per-lchan
detection of missing bursts and NOPE indications in TRXDv1.
* [1] per-lchan detection of missing bursts was fixed in Aug 2018.
* [2] TRXDv1 support was introduced in Jul 2019.
Today is 2022 and it makes no sense to keep this hack. Even if
the transceiver does not support TRXDv1, per-lchan detection
will compensate the missing Uplink bursts.
Change-Id: Ic292d180ba64206fb4d88adb284f9f9d058b4587
Related: [1] I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: [2] If61c71d20d590bf07bfd019afb33000a0b6135bd
The gitlog shows that these warnings were added in
744f745d7a by jolly (in 2012!).
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: Iebf9961cffbd7aa20b263f7dc0016a44782dec60
Related: osmo-bsc.git I9ef7e18f56aa86b48f0ffeec58406260736170f3
OsmoBSC assumed since If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28 that
OsmoBTS has CCN (NACC, Network Assisted Cell Change). With OsmoBSC
Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, instead of hardcoding some
features for OsmoBTS in OsmoBSC, only the features reported by the
BTS are used. Therefore report that BTS_FEATURE_CCN is supported in
OsmoBTS.
For previous OsmoBSC versions, this fixes the message:
Get Attributes Response: reported feature 'CCN' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ic407e3be82afe61ed64b1cecf3dc94d2caff380a
I did not realize with my previous patch that there's a common place
where features available for all backends should be enabled. So move it
there.
Related: SYS#5922, OS#5538
Change-Id: Id688ddae5cd714355fcc5324f33c9397fecae261
According to osmo-bsc I0e80ca5afc06737273b6699bde6e325e454b57f6, the
PAGING_COORDINATION feature should be well supported in osmo-bts. Adjust
the bts_model_init functions to report this to the BSC, so it properly
sets this in SI13 and so we can avoid this notice in the log:
Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ib06829501f4221a7f7b0344ec7991ceba74e7641
Currently (without this patch) if tch_dl_dequeue() yields nothing we're
scheduling dummy FACCH/H *regardless* if it's permitted to start at the
given TDMA FN or not. This may result in misaligned FACCH transmission,
so the MS will not able to decode anything and will report BER>0.
With this patch applied we schedule FACCH/H if it's allowed to start
at the current TDMA FN; otherwise send half-filled bursts with even
numbered bits contaning 232 encoded bits of the previous L2 frame
and 232 odd numbered bits all set to 0.
This patch does not guard against sporadic gaps in the Downlink TCH
queue. However when tch_dl_dequeue() constantly yields nothing, e.g.
when we end up with a codec mismatch, then this additional check saves
us from starting misaligned FACCH/H transmission. If we start at a wrong
TDMA offset, then all subsequent FACCH frames will be scheduled at wrong
offsets and thus none of them will be decoded by the MS.
Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b
Related: SYS#5919, OS#4823
* dl_ongoing_facch must be set for correct FACCH/H scheduling;
* dl_facch_bursts must be set for FACCH overpower to work.
Change-Id: Ief12eb67ad80de3b71f5226858dc2e0c8ae76948
Related: SYS#5919, OS#4823
If set, chan_state->dl_ongoing_facch indicates that we're sending
the 2 (out of 6) middle bursts of FACCH/H. In this case there is
no room for encoding an additional frame, because both even and
odd numbered bits are occupied by a previously encoded FACCH/H.
Right after calling tch_dl_dequeue():
* do not check the dequeued message against NULL,
* do not compare the message length to GSM_MACBLOCK_LEN,
* immediately free() it and jump to the sending part.
Change-Id: Ib923b8f5cc1063e9fc18acd2bdd003fd09f4b70f
Related: SYS#5919, OS#4823
Unlike SACCH, FACCH has no dedicated slots on the multiframe layout.
It's multiplexed together with TCH (speech or data) frames basically
by replacing (stealing) them. This is common for both TCH/F and
TCH/H, with the only difference that FACCH/H steals two TCH frames
(not just one) due to a longer interleaving period.
Let's implement the multiplexing in the common function, which is
used to dequeue to be transmitted frames - this slightly reduces
code duplication. Use a new name, so that it's clear what it does.
Change-Id: I9822b1a17185d5487f0f6d3ed0203e806c053d7d
Related: SYS#5919, OS#4823
Manual analysis of code didn't end up in finding any issue, so this
seems a false positive (I can really understand gcc failing to do proper
job here, this function has way to many jumps here and there.
"""
/sched_lchan_tchh.c:88:13: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
88 | int rc, amr = 0;
| ^~
"""
Change-Id: Ifebaee63a9dad04976ffb4438c32360687ef095a
Keep collecting C/I samples even if the MS has not yet applied
previously requested codec mode. The C/I ratio is expected to
stay more or less the same, no matter which codec mode is used.
Change-Id: Ieb5473ead7200f652b5d0e339e4e252d6567482d
Related: SYS#5917, OS#4984
With the current implementation the AMR loop is unable to upgrade
the current codec mode unless it reaches the worst possible value.
The problem is in the 'else' statement connection both 'if's.
Change-Id: I4c0fb28813373c3d4addd28c66f5136d2c4f9ed8
Related: SYS#5917, OS#4984
Currently we're logging AMR mode *indexes*, not the actual modes.
Let's make it cleaner for the user by logging both mode and index.
Change-Id: I4feb3a3823799a290a50a48275e45f3331874d1a
Related: SYS#5917, OS#4984
Looks like this structure was copied from openbsc/osmo-bsc as-is.
The ms_mode[] makes no sense in the context of BTS, so remove it
and rename bts_mode[] to mode[] for the sake of brevity.
Change-Id: I7442360ed857554440a0b9854f2d2bbab9dc5a71
Related: SYS#5917, OS#4984
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I18ebb7395024a490da743c0bcb20959e6e9c7017
This unit test demonstrates a problem in amr_parse_mr_conf(): the
threshold and hysteresis values are parsed incorrectly. They are
expected to match what we have in amr_fr_bts_mode_def[]:
Mode[0] = 0/13/4
Mode[1] = 2/25/4
Mode[2] = 5/37/4
This will be fixed in a follow-up patch.
Change-Id: Iab7e8878e62f598959e80fcb7e729b7f496962a2
Related: SYS#5917, OS#4984
Both misc_test_{SOURCES,LDADD} were simply ignored because
binary 'misc_test' is not listed in noinst_PROGRAMS...
Change-Id: Ia1739bab76261ff6d50824462b8ed2e0b34fb464
Related: SYS#5917, OS#4984
This configuration will be used as a fall-back when the MultiRate
configuration IE is not included in the CHAN ACT/MODIFY messages.
Change-Id: Ie96af636105ee1ffe2d9a0bd9eea375faebad149
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917, OS#4984
Normal blue (34) is really hard to read on terminals with dark
background. Let's use light blue (94) instead.
Change-Id: Iadc9b8fb74ec17455435893a532c2f12e02cb804
3GPP TS 48.058 defines the MultiRate configuration IE as optional,
and states that it's "included if the Channel Mode indicates that a
multi-rate codec is used". If I understand this correctly, it may
be omitted even if a multi-rate codec is requested. Otherwise it
would have been defined as a conditional IE.
For now let's print a warnig if this IE was expected, but missing.
We may need to apply some hard-coded defaults in this case.
If this IE is present, but the Channel Mode indicates a codec other
than AMR, let's send NACK with cause=RSL_ERR_OPT_IE_ERROR, assuming
that the CHAN ACT/MODIFY message is malformed.
Change-Id: I6ddc0b46a268ed56ac727cda57d0d68b2746fd59
Related: SYS#5917, OS#4984
There is nothing else except the AMR link adaptation loop in these files.
Change-Id: Iff2c0d32da5cd89824197d05f4732ce974c12f28
Related: SYS#5917, OS#4984
This check is redundant because it's guaranteed in rts_tchh_fn()
that FACCH/H is always scheduled at the correct frame offset.
Change-Id: I2f0c26f6007455aa1e3e8b27bc9d173f6b1f8c38
Related: SYS#5916, OS#5518
Since change [1], in rts_tchh_fn() we're using a lookup table for
DL FACCH/H. Let's do the same for UL FACCH/H in rx_tchh_fn().
Change-Id: I7c4e3befdd33bef4d89a04a4c7cb1a2d4078c156
Related: [1] I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
Unlike TCH/F, TCH/H imposes some additional requirements on the FACCH
transmission, so that a signalling block can be transmitted only at
specific TDMA frame numbers defined in 3GPP TS 45.002, table 1.
This is why in rts_tchh_fn() we need to check the given TDMA frame
number and tell rts_tch_common() whether FACCH/H is permitted or
not. The check is based on a magic formula, which I find a bit
hard to read and understand. Let's better use a lookup table.
Change-Id: I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
It's guaranteed by the calling function bts_model_l1sap_down() that
the prim's operation is PRIM_OP_REQUEST and that the msg is present.
Change-Id: I6a01bba7b5eb337ae1552c442d74447565c52e25
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: If7c804e51eb104d9fe73294a3867ab3b551d83c3
In change [1] I didn't take into account that the TCH/H burst buffer
is 6 bursts wide, and that we're decoding 2 bursts late:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
The lookup table for TCH/H was calculated with the assumption that
in rx_tchh_fn() the 'bi->fn' indicates TDMA frame number for burst
'd', but in reality it holds the frame number of burst 'f'.
Change-Id: I4f22cf49fd52ed26f8017f76461059a701c181e1
Fixes: [1] I46def864729c8f9063af201750456771ea5558d5
Related: SYS#5916
It makes no sense to have these tables in the header file, because
they're not used anywhere outside of the respective lchan handlers.
Change-Id: Ibdebfb9b1ef78c960b08240ebdb4c7af92cbed11
Related: SYS#5916
In change [1] I broke measurement reporting for TCH/H in signalling
mode. The problem is that in rx_tchh_fn() we started to invalidate
the Uplink RSSI for FACCH regardless of the channel mode: speech or
signalling. In speech mode, the averaged measurements are carried
over by the two BFIs. In signalling mode we send no BFIs, so:
* let's use the proper averaging mode S6N6 (not S6N4), and
* send the averaged measurements together with the FACCH.
This change fixes BTS_Tests.TC_meas_res_sign_tchh[_toa256].
Change-Id: If98aa1f0f7255f20344460bdd07e2c896dd6e56f
Fixes: [1] I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: SYS#5853
There is no reason not to use 'chan_state->tch_mode' directly in
the 'switch' statement. If a logical channel is in signalling
mode, then both 'chan_state->{rsl,tch}_cmode' are set to
RSL_CMOD_SPD_SIGN and GSM48_CMODE_SIGN, respectively.
Change-Id: I9e5e2c891c80c32fc522b53c9371b71ea32dd54d
Related: SYS#5853
3GPP TS 45.009 defines that Codec Mode Indications shall be sent
with speech frames having specific TDMA frame numbers of their
*first* bursts, which are defined in tables 3.2.1.3-{1,2,3,4}.
Performance-wise it's batter to have these tables implemented as
arrays, rather then using the 'switch' statement. We can simplify
things even further and have TDMA frame numbers corresponding to
the *last* bursts in them. This eliminates the need of doing an
additional last-to-first mapping, so that bi->fn can be used.
Change-Id: I46def864729c8f9063af201750456771ea5558d5
Once we have an Uplink speech or FACCH frame decoded, we need to
hand it over to the upper layers indicating TDMA frame number of
the *first* burst corresponding to the beginning of a block.
Currently we use libosmogsm's gsm0502_fn_remap() API to calculate
the first TDMA frame number from the given last frame number.
This API involves iterating over the pre-calculated offset tables
for different channel and payload types, and thus imposes some
additional CPU cycles. Another downside of the current approach
is that we have to perform such lookups several times for each
decoded L2 frame, e.g. for FACCH on TCH/AHS we do it three times!
In this patch I propose an alternative approach of storing TDMA
frame numbers in the measurement history, together with the
associated samples. This way we can easily get N-th frame number
from there without performing any additional computations, other
than what we already do during the measurement processing.
Change-Id: Id9a2b7b0f1a1ad7cfbbab862faf521e135c90605
The idea of this change is to avoid attempting to decode the burst
buffer unless it's filled up completely. This eliminates expected
decoding errors in the beginning of lchan's lifetime. Moreover
this allows us to be sure that the measurement history is complete,
so that we can abuse it to store TDMA frame numbers later.
Note that even in the absence of NOPE indications (TRXDv0 case)
we can still be sure that the burst mask has no gaps due to lost
bursts, because they are compensated by trx_sched_calc_frame_loss().
Change-Id: I56bebe1374eb803e3c1e9f08dda4da50a074ab0b
For both TCH/F and TCH/H, the receive burst buffer needs to be
periodically shifted leftwards due to the nature of block-diagonal
interleaving. Currently we do this on receipt of bid=3 for TCH/F
and bid=1 for TCH/H, right after attempting to decode the buffer.
If for some reason we return early before attempting to decode the
buffer, the content of that buffer might not be shifted and some
bursts might be overwritten. This can be easily avoided by doing
the shifting on receipt of bid=0 for both TCH/H and TCH/F.
Change-Id: I0bd69f5a8f5c665fb5f00c127bc3fe1d91167abb
In the current implementation of both TCH/F and TCH/H lchans, we
set the 'bfi_flag' to true only if decoding fails. Perhaps this
was not the case when I wrote [1], so using meas_avg might result
in using uninitialized memory. This is not the case anymore.
Pass the *averaged* measurememnts regardless of decoding result.
Change-Id: I23f767364a018d30d04885990adf69b50b2c9738
Related: [1] I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
FACCH/H takes out two speech frames, so we send two BFIs once we
have received it in rx_tchh_fn(). The upper layers responsible
for handling of the Uplink measurements expect a fixed amount of
measurement samples, so currently we do:
* send a FACCH frame with the associated measurememnts (S6N6),
* send the 1st BFI with invalidated measurements (RSSI=0),
* send the 2nd BFI with the stored measurememnts of FACCH.
This is achieved by preserving a copy of the FACCH measurememnts
in chan_state->meas_avg_facch and then using it two bursts later.
The same goal can be achieved a lot easier by sending the associated
measurements with both BFIs as if no FACCH was received:
* send a FACCH frame with invalidated measurememnts (RSSI=0),
* send the 1st BFI with the associated measurememnts (S6N4),
* send the 2nd BFI with the associated measurememnts (S6N4).
This eliminates the need to store anything outside of the existing
measurement history and simplifies the code a lot. Also, this
eliminates the need for using a dedicated averaging mode S6N6.
Varified by running BTS_Tests.TC_meas_res_speech_tchh_facch.
Change-Id: I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
It makes no sense to store BER10k value of an Uplink FACCH frame
in order to indicate it in a BFI later on. Given that these BFIs
are generated artificially, it's fine to indicate BER10k=0.
Change-Id: I24d12892760dca0ad0a5c2abca9fc66523d9e614
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. C1/TS2 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Without this change osmo-bts does not send CBCH Load Indications
at all if the CBCH is allocated on C1..n.
Change-Id: Ib5976783b53521047fbdfc18e0e236e8bce8eaae
Related: osmo-bsc.git Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
Both TRXC_RACH and TRXC_PTCCH are handled in the rx_rach_fn(),
so we can eliminate the need of having a 'switch' statement in
the general (perfrmance critical) code path.
Change-Id: I66d8785a63215af37a77e258039549e4e6292e49
Compared to TCH/F, TCH/H is a bit special in a way that:
* speech frames are interleaved over 4 consecutive bursts,
* while FACCH frames are interleaved over 6 consecutive bursts.
This is why in rx_tchh_fn() we allocate a buffer large enough to
store up to 6 bursts. Let's say we have that buffer filled up
completely with all 6 bursts (from 'a' to 'f'). Now attempting
to decode them may yield either a speech frame or a FACCH frame:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
For FACCH we use measurement averaging mode SCHED_MEAS_AVG_M_S6N6,
so that 6 last samples are averaged - so far so good. For speech
we use SCHED_MEAS_AVG_M_S4N4, so that 4 last samples corresponding
to bursts 'c', 'd', 'e', 'f' are averaged - this is wrong.
We actually need to average the *first* 4 samples corresponding to
bursts 'a', 'b', 'c', 'd' in the case of speech. Let's add and use
a new averaging mode SCHED_MEAS_AVG_M_S6N4 for that.
Change-Id: Iea6f4e5471550f4c2b57aaebeac83c80e879489d
This should be better performance-wise and would also allow to avoid
having the same switch statement duplicated in functions added later.
Change-Id: If8124dcd38e7c8408a9f3b9a574d9e3181a2eb15
This is a purely cosmetic change. The new naming clearly indicates
how deep to go back in the measurement history (S) and how many
samples to average (N). For example:
* SCHED_MEAS_AVG_M_S4N4 - go S=4 steps back and average N=4 samples;
* SCHED_MEAS_AVG_M_S6N2 - go S=6 steps back and average N=2 samples.
Change-Id: I96a8dd08084c7c179f879fc00e75c5edcfb11caa
Set the FT (Frame Type) in the ToC (Type-of-Content) section as
defined in section 5.2 of RFC 5993. Before this change SID frames
had FT = 000 (Good Speech frame), because gsm0503_tch_hr_decode()
does not distinguish between speech and SID frames internally.
Change-Id: I09cec984bb60c754908126acf0300a2cc602485c
Related: SYS#5853
According to RFC5993, which is referenced by 3GPP TS 48.103, the
complete RTP HR payload consists of a Table-of-Contents (ToC) byte
followed by the 14 bytes of the HR codec frame. See section 5.2.
gsm0503_tch_hr_decode() outputs frames in the RTP format with
length of 15 bytes (120 bits): 1 (ToC) + 14 (HR frame):
+-------------+-------------------------
| ToC section | HR codec frame ...
+-------------+-------------------------
osmo_hr_check_sid() expects a HR codec frame of 14 bytes (112 bits)
as the input, so we should skip the ToC section when calling it.
Change-Id: Ie5fa776dcb2b2203a97aed56ecbf2450af7d87c1
Related: SYS#5853
According to 3GPP TS 48.058, section 4.1.4, BTS shall start transmission
on SACCH if both MS Power and *Timing Advance* IEs are present. There
can be no Access Delay IE in the RSL CHANnel ACTIVation message.
Change-Id: Icd8ccfd6e37ded8966125a473b5003845ba87fec
Fixes: I170b63c9856230d5f1a10654a9d950ada8e730d7
Related: SYS#5838
We already have BER10k calculated in the generic code path, so do
not calculate it once again in the FACCH specific branch.
Change-Id: I5d3955d09990e280d11d687385eeaf5edf437395
It makes no sense to perform the SID codeword lookup in signalling
frames (FACCH), because it can be present only in speech frames.
Change-Id: I2f8137993acfe8a8add3fc2af276e5eb4da1605e
Related: SYS#5853
Most of the BTS specific VTY commands restrict BTS number to '<0-0>',
while bts_c0_power_red_cmd has '<0-255>'. This confuses libosmovty:
OsmoBTS# bts ?
<0-0> BTS number
<0-255> BTS Number
OsmoBTS# bts 0 ?
% Ambiguous command.
OsmoBTS# bts 0 c0-power-red 0
% Ambiguous command.
Let's stick to '<0-0>', we don't support multiple BTS anyway.
Change-Id: I937ac421143678b97627c1bc4fe573831ce097f6
This new rate counter allows to monitor the efficiency of the
radio carrier cache used for routing Downlink bursts when
baseband frequency hopping is in use.
Change-Id: Ie6da829e47298476267c8df2dcedafad564cbbb4
Related: SYS#5855
Given how often we send and receive TRXD PDUs, I believe it maks
sense to use OSMO_UNLIKELY() in the error checking conditions.
Theoretically this should improve performance.
Change-Id: I9266aaf2bbc0acfe21e9bfb12c9f38621d120553
This avoid a NOTICE log line like the following when gsm_lchan_release()
is called.
"""
rsl.c:2484 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: cause = Normal event, unspecified
"""
Change-Id: I0ce78c52644983220f5810bc5c661b07afd9e543
If len is < 0, it means osmo_amr_rtp_dec() failed and some of the out
variables there are not set. We should check the return code before
continuing and using potentially uninitialized values.
Change-Id: I76020c6b5dc8d3e52e8c5be8cdecdf8a0bb52ed9
DSUM is somewhat similar to DMAIN, generic logging category used
in other Osmocom projects. This category is rarely used in a few
places, where the other categories could fit better. Remove it.
Change-Id: Ia9db783bc92b23ba87b4fdf1e4ed07d59ea6bbce
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I12b250e16426b125124def49e124e40ae93d0d58
An additional burst buffer is allocated in rx_data_fn() for Uplink
SACCH repetition, but unlike the main buffer it never gets free()d.
Change-Id: I93310e7aed91a49c0511e2ed30e000440617f95a
Fixes: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
Before a massive refactoring of the scheduler structures [1] it was
impossible to have a clean hierarchy, in which the burst buffers
get allocated as children of their parent timeslot structures.
This change makes it easier to read talloc reports and simplifies
memory management, offloading free()ing of the burst bufferes to
talloc.
Change-Id: Idb1ceaf83c433d2d0eb84d77c2187a00a657905c
Related: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
Add an osmo-bts meta-package that depends on the subpackages
osmo-bts-trx and osmo-bts-virtual. This is important, because the
downstream packaging of debian does not split osmo-bts in subpackages,
it has only one osmo-bts package. So without this, when installing
"osmo-bts" in debian while having the Osmocom binary package repository
installed and expecting to get the newer version, the user will actually
get the older version from debian.
Closes: OS#5319
Related: https://salsa.debian.org/debian-mobcom-team/osmo-bts/-/blob/master/debian/control
Change-Id: I1a6edf2eb146616ac51b7957368a8d057caa685f
Callers of osmo_wqueue_enqueue must always check the return value
and free the message themselves in the error case.
Change-Id: Ic67fbef23e419c0c8a7bcfb16d134e1bf649de72
Related: OS#5329
If a new default message is installed via RSL, and the old default
message is currently being transmitted, we must set cur_msg to NULL.
The old default message must be talloc_free()d unconditionally whenever
a new default message is being set.
We can do that by using the TALLOC_FREE macro.
Change-Id: Id32c2074b61cd1f09957b9d1558ffb3a7691a8e0
Related: OS#5325
If the currently transmitted message is the default message,
bts_ss->cur_msg == bts_ss->derfault_msg. In this case we cannot
simply talloc_free() both of them, as it would result in a boudle-free.
Change-Id: I2d3645e34d31507b012a53ffe12d14223682f808
Closes: OS#5325
Fixes: Ib01d38c59ba9fa083fcc0682009c13d2db3664fe
The order of interference level boundaries is not clearly defined by
3GPP, so we should support both ascending and descending variants.
Change-Id: I88d841d8d835bde8392c7b606b28c9070b7adc6e
Related: SYS#5313
It may happen after the A-bis connection recovery that the RF RESource
INDication message gets sent too early, while some timeslots are not
yet configured. This confuses the BSC and provokes error messages.
Change-Id: I00bc6fe67ea1bbedcd5d8640e73bd8b16b9e667f
Related: SYS#5313, SYS#4971
Let's make sure all ts->pchan* related data is reset when we release the
TS. This is important for pchan_is, since in bts-trx upon shutdown
finish the PDCH lchan of a osmo dyn TS is set to
lchan->state=LCHAN_S_NONE, and as a result when the PCU tries to release
it by means of PCUIF act_req later, it may be ignored since the lchan is
already in erased state.
Related: SYS#4971
Change-Id: Ic7c34c0de23101ce094ffd03e00b4d2f6a551152
As a side effect, we have to sacrifice a unit test (TC_inval_dummy)
because it becomes impossible to pass a dummy or invalid SACCH block
to lchan_bs_pwr_ctrl().
Change-Id: I937117cf26fb718d57920382f6972390ad498c51
Related: SYS#4918
The current Timing Advance value can be obtained either from the
L1 SACCH header (if received) or from lchan->ta_ctrl.current.
Change-Id: I2b3693a0e49f03f2b4496c9dbd30cf47e9bc86b5
Currently an Uplink SACCH block is being passed to LAPDm first, and
then gets forwareded to the BSC in handle_ms_meas_report(), together
with the Uplink measurements collected so far.
This approach has a serious flaw: handle_ms_meas_report() won't be
called if an Uplink block contains SAPI=3 data (SMS) or was not
decoded at all (len=0) fow whatever reason. Therefore, no RSL
MEASurement RESult message will be sent to the BSC.
Rename handle_ms_meas_report() to lchan_meas_handle_sacch(), and call
it from l1sap_ph_data_ind(). This way perioduc RSL MEASurement RESult
messages will be sent regardless of what happens on Uplink SACCH.
Change-Id: Ifed91f87fd653debc87a09da3fd31ad64a13f330
Fixes: TC_meas_res_speech_{tchf,tchh}_sapi3
Related: SYS#5319
This way we keep all BTS connected to the same BSC if there was a
spurious network problem.
Related: SYS#4971
Change-Id: I16b75da5987584d099edc3a640f3a5cd61f3ad69
priv->current_bsc will for sure be != last, otherwise it would have
entered the if clause above it.
Change-Id: I0a6519f7b93f0b45c67d19fef4f50daeeefc7340
This scenario is actually expected when the call is being set up or torn
down, since we may not be receiving RTP from the MGW to send to the MS.
Hence, let's lower the log level to DEBUG to avoid having log clogged
for each call start/stop if INFO is used.
Related: SYS#5676
Change-Id: Ib7f274b97cc66d671316eae429ee4baf16831534
Recent commit (see below) changed a check to avoid weird results for msg
which had l2h=NULL, since l2len would return unexpected results there.
However, some code branches like FACCH or TCH seem to be always setting
l2h even if len=0. Hence, we must test either of the 2 scenarios (null
pointer and l2len()).
This commit fixes the following message appearing all the time during
calls:
"""
TCH/F: Prim has odd len=0 != 23
"""
Fixes: fb905b8d23
Related: SYS#5676
Related: SYS#4919
Change-Id: I43152bc8484a35cd004d3303d3a6e6efcdefa890
It cannot happen that msg1 is NULL and msg2 is not null, since they are
deuqueed from same place. Only possible combinations are:
msg1!=NULL && msg2!=NULL
msg1!=NULL && msg2==NULL
Change-Id: Ifd789844b1a7dfba596664de440d4c20b9f4c78f
* Remove deprecated configuration options:
'osmotrx timing-advance-loop' is deprecated, Timing Advance loop is now active by default
'osmotrx ms-power-loop <-127-127>' is deprecated, MS Power Control is now managed by BSC
* Adjust 'ipa unit-id' (1801 -> 6969) to match the one from the example osmo-bsc.cfg
* Set clock advance values to known working values:
+ 'osmotrx fn-advance' -> 20
+ 'osmotrx rts-advance' -> 5
* Set 'nominal-tx-power' since the calypso-bts tranceiver does not support NOMTXPOWER
Change-Id: I69436b914cf1bec57f9fe7acea4a896e7c46b3a9
In 2/3 cases when calling process_l1sap_meas_data() we already have
a pointer to the logical channel, so let's pass it as the first
argument instead of a pointer to the transceiver. This way we
avoid calling get_active_lchan_by_chan_nr() two times.
In l1sap_ph_data_ind(), call process_l1sap_meas_data() below the
conditional branch handling PDCH, so it won't be called for
GSM_LCHAN_PDTCH anymore. GPRS specific measurements are handled
by the PCU and not of interest for the BSC.
Change-Id: I9de67a0b2d2b18923f2c2003b400387a0f1af411
After merging the patch [1] fixing handling of the RLL RELease
INDication message in lapdm_rll_tx_cb(), ttcn3-bts-test shows
several regressions:
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_3
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_3
pass->fail: BTS_Tests_LAPDm.TC_sabm_dm
[1] I823c9101bcca72d5792e16379b02d3602ffc2726
991020c049
The problem is actually *not* in patch [1], but in the older one
[2] which we attempted to fix. While a logical channel is in
signalling mode, the lower layers do not produce PRIM_TCH_RTS,
and thus the l1sap_tch_rts_ind() is not being called.
Unlike l1sap_tch_rts_ind(), the l1sap_ph_rts_ind() is being called
regardless of the channel mode (signalling vs speech), so let's
move handling of lchan->pending_rel_ind_msg there.
Change-Id: I2c380f9045624f0a0a8f988bb207bc73d8354857
Fixes: [2] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
It could happen if for instance l1 code called trx_sched_clean() when
closing the phy, and after that some code called (erroneously)
trx_sched_set_lchan(). Let's make sure we don't allow other modules to
crash the process when using this function.
Related: SYS#4971
Change-Id: I93af7c3dcf0e34e9317eec0ee183dbf18b8d2f3b
This avoids triggering all sorts of unexpected paths where one tries to
release an already released lchan, etc.
This can happen for instance if BTS shuts down due to BSC link going
down, and hence resets all lchans, announcing it to the PCU. Then the
PCU may try to deactivate the channel sending act_req (disable), but the
BTS already unilaterally dropped the channels.
That code path seems to trigger some crash, probably because something
in lchan has been freed.
Related: SYS#4971
Change-Id: I093e4d4e23b527b10bf5d6ff538460626c30a8f8
The burst is properly pre-filled to _sched_dummy_burst in
bts_sched_init_buffers(), so we are fine doing nothing on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: Ia7045724a1a3206f5890c0b12843711ad2360ed8
msgb_l2len() will return nonzero values if msg->l2h is NULL.
Let's check against msg->l2h being NULL instead.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
This reverts commit 8a85b71167.
This is actually the wrong fix. Proper fix comes as a follow-up patch,
since the root cause happens earlier in upper layers. No msg with
l2h=NULL should reach this point of code ever.
Change-Id: Ie23d94924f824bd7e89437ccf73b260f542477c6
PCU idle blocks are identified by being 0 length, and hence msg->l2h
being null. Don't try to encode those, but simply discard them silently.
In case there's a missing block in C0, we want to log the event since
the BTS is expected to send something on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I57e215fedeb415db4e67fdc56bf0f1410b5f7130
With this change the error case is moved at the end of the function,
which is more usual. At the same time, one goto tag can be removed,
simplifying the function.
This is also a preparation for next patch improvinga bit the logic
around same place.
Related: SYS#5676
Related: SYS#4919
Change-Id: Ifbd95ccbebf4d810b1fe0a162722e63fe69106b8
The new [bit-]fields in the RSL_IE_OSMO_TEMP_OVP_ACCH_CAP allow
more fine-grained control over the overpower feature, which
can be enabled:
* for both SACCH and FACCH,
* for SACCH only, or
* for FACCH only.
Change-Id: Iaaab675a20bbefece832d913963c8c5ae32ff80c
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
This adds a --enable-systemtap configure option, which will then
add static tracepoints to the generated osmo-bts-* binary.
At this point, only two sets of tracepoints are supported, and
only in osmo-bts-trx: ul_data_{start,done} and dl_rts_{start,done}.
The probes are intended to be used for analyzing the amount of time
needed for processing of uplink bursts / generation of downlink bursts.
Change-Id: Ibb4962253f1a195dc1a54405bac058ccb2545799
During the merge of [1] the patch hunk was applied at a slightly
wrong location, so the code path has become unreacheable.
Change-Id: I823c9101bcca72d5792e16379b02d3602ffc2726
Fixes: [1] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
A logical channel may have associated messages, which are pending
for transmission until some event occurs. Do not leak them.
Change-Id: I3264e6caa007e9e9cb9c1c2f8627c408bbb28b9e
In repeated_dl_facch_active_decision() we rely on the Measurement
Report message, that in some cases may not contain valid Downlink
measurements. In this case, we should simply ignore it.
Change-Id: I0d72b454f2b770d5762303fb70a15a8cdc9d07d7
Related: SYS#5114
For the sake of consistency, call repeated_dl_facch_active_decision()
from handle_ms_meas_report(), so we have all functions using the
measurement results for Downlink executed in a single place.
Change-Id: Ibd5377ce642e49161f320ac8c33e9f966b3ddfaf
Related: SYS#5114, SYS#5319
A bit of archeology, history & recap:
ec1b5a0e9e2b6549e0ede48e803095e569997355 (openbsc.git) Adds assert in gsm_ts2chan_nr()
2f44693fad8505255293d3ed37dbd4e7cabebd37 (openbsc.git) ASSERT is disabled due to reported hit in octphy and
litecell in gerrit for ec1b5a0e9e2b6549e0ede48e803095e569997355
5cef0623ef (osmo-bts,git) minor fixes to gsm_ts2chan_nr() regarding the pragma
c9079d9106 (osmo-bts.git) GSM_PCHAN_NONE case is introduced in gsm_ts2chan_nr()
This code has long evolved and robustness has improved, it's not even
part of openbsc.git for several years now. Let's always assert if we
receive an unexpected value there, since they are all internally handled
values and hence we have control over them.
Related: OS#2906
Change-Id: I25e2cf0c922bc9902336e9add75a47535b9355bf
It can happen when using several TRX that all of them go alreadyunder
shutdown target tx power level, but that due to configuration the BTS
still may want to keep pushing the tx power level even lower. Hence, we
end up in a situation where the FSM is trying to close all the TRX while the
power ramp procedure is ongoing for some of them. As a result, race
conditions can happen where for instance the power ramping procedure for
one TRX ends and calls the cb to send SETPOWER after the TRX PHY has
been closed (and hence TRXC link is unavaialble).
If that happens, the trx_if lower layers store the SETPOWER and attempt
a later retransmit, which may take up to 2 seconds after TRX becomes
active if BTS reconnects immediatelly.
Hence, we end up in some test cases where BTS reconnects and configures
some TRX while others are kep unconfigured for a while due to the
mentioned delay, hence the test attempting to use the TS while it hasn't
been yet configured.
The solution is to avoid this kind of unexpected events with ongoing
powe ramp once we have decided tx power is lower enough to shutdown the
TRX completely. Hence we abort the pending power ramp procedure.
Change-Id: Ibca581131eb142d7c38c917a0d6990efec03123c
Fixes crash when TTCN3 BTS_Tests_LAPDm TC_rr_response_frame_loss
runs run after TC_t200_n200.
The BTS was shutdown after TC_t200_n200 failed (drop oml link), and
lchan was moved ACTIVE->NONE without lapdm_channel_exit() being called
on it. Hence, on next test (TC_rr_response_frame_loss), when
lchan_init_lapdm() was called again, some memory corruption was caused.
The lapdm_channel_exit can be dropped from gsm_lchan_release() and
rsl_tx_rf_rel_ack() since it's already called in the same path:
"""
rsl_rx_rf_chan_rel
gsm_lchan_release(lchan, LCHAN_REL_ACT_RSL);
l1sap_chan_rel(lchan->ts->trx, gsm_lchan2chan_nr(lchan));
l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE)
bts_model_l1sap_down
bts_model_lchan_deactivate_sacch(lchan);
-
lchan_deactivate(lchan);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_NONE); <---------
mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0);
l1sap_info_rel_cnf
rsl_tx_rf_rel_ack(lchan);
lapdm_channel_exit(&lchan->lapdm_ch);
lapdm_channel_exit(&lchan->lapdm_ch);
"""
Related: SYS#5262
Change-Id: If0ec5f0c7be4d15c8d684d33e15e24d68bd5192e
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
Let's avoid running over state change conditions or even printing log
lines if there's no state change.
Change-Id: I1ca86aa846084f53751076643665cb6dabc26a06
There's no need to re-setup it every time.
Mark the cb as static since its private to the module, and move it
above its use point so it can be referenced.
Change-Id: I90324f26d8ca09d425c7523a25b3e6c951fa49d6
* Move way too verbose command description to the manuals.
* None of these commands apply immediately, correct the attributes.
** Remove meaningless call to l1if_provision_transceiver_trx().
* Make 'maxdlynb' hidden, so it only appears in the expert mode.
* One GMSK symbol actually corresponds to 550m.
Change-Id: I46839cf56bba2dcdc70303cd393e86d35aa2f3f5
trx_phy_inst_open() already guards against NULL trx ptr when calling
trx_sched_init(). Later on, in same path, trx_phy_inst_close() can be
called which ends up calling trx_sched_clean(trx), this time not being
guarded against NULL trx. This fixes Coverity CID#240498.
Fixes: CID#240498
Change-Id: I00afc739559d57dd98db68c76f2a85006c15e875
- one gsm symbol is 0,00000369 seconds
- 2*550m/c = 0,00000366 seconds
-> one ta symbol is a DISTANCE of 550m (or a RTT of 550m*2) between bts and ue.
-> no idea why this was constrained to TA/2.
Change-Id: I8d79080c82411e6427eec37d008614fa5d5e1ace
Related: OS#5140
The OML NM Channel FSM state only apply to primary timeslots, hence we
need to make sure we pick the primary TS (the non-shadow one).
Due to this bug, all channels on shadow TS where NACKed because the
related state was never "Enabled Ok".
Fixes: c97a7f51e1
Related: OS#5249
Related: OS#5251
Change-Id: If47e4bdd45a05ed1b5709b6e3d541f2830723e37
Since non-shadow TS are currently not allocated as talloc contexts,
lchan objects tend to allocate their own memory on trx talloc ctx
instead. That's fine for non-shadow TS, since the TS follow trx lifecycle
since they are part of the same talloc context. However, shadow TS are
recreated (re-allocated) each time the BTS reconnects, hence when htey
are freed we need to free substructs (lchan) memory in order to avoid it
being kept in trx talloc ctx.
Related: OS#5248
Change-Id: I73742535eb3c40a6866731acbff782940dab06c3
Code in oml.c, upon receiving net attributes, merges the new attributes
with old ones (for some reason I don't really know). Hence, if we
disconnect from a BSC and go to NOT_INSTALLED state, we must free
previous nm_attr in order to avoid mixing them once we connect to a new
(potentially different) BSC upon reconnect.
Related: OS#5248
Change-Id: I45cc22dd68121a7930301581bfd0a8db37879c77
Let's rather put it there instead of the shutdown code path, since we'll
be adding more and more reset coe there.
Change-Id: I43a136ade731a2c58c0a29d97875088e9b6d4414
Currently, only osmo-bts-trx is capable of reporting the interference
levels to L1SAP. Thus it does not make sense to trigger the averaging
logic and send empty reports over the A-bis/RSL and the PCUIF.
Change-Id: Ic17eb46bdca3c33ac4d6e560a093b635b75424a5
Related: SYS#5313
Starting from [1], interference levels on PDCH timeslots are also
reported over the A-bis/RSL. They may be useful for the BSC to
determine whether dynamic PDCH timeslots might be better used for
new circuit switched connections, or whether alternative PDCH slots
should be allocated for interference reasons.
* Handle GSM_LCHAN_PDTCH in lchan_report_interf_meas().
* Rework pcu_tx_interf_ind() to accept 'struct gsm_bts_trx'.
* Call pcu_tx_interf_ind() from l1sap_interf_meas_report().
Regarding pcu_tx_interf_ind(), it's better to call this function
from the upper layers once, rather than calling it from various
places in the model specific code.
[1] I5b4d1da0920e788ac8063cc765fe5b0223c76758
Change-Id: I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Related: SYS#5313
This information may be useful for the BSC to determine whether
dynamic PDCH timeslots might be better used for new circuit
switched connections, or whether alternative PDCH slots should
be allocated for interference reasons.
Change-Id: I5b4d1da0920e788ac8063cc765fe5b0223c76758
Related: SYS#5313
It's cleaner from the architectural point of view to have the
interference measurements processed in a separate function.
Change-Id: I3981608e01a50585359cad673c38c8a305027d30
Related: SYS#5313
It may happen that the BSC requests logical channel activation on a
dynamic timeslot, which is in a process of switching from one pchan
type to another due to a preceding channel activation request.
In this case 'struct gsm_bts_trx_ts' already holds an msgb with the
preceding RSL CHANnel ACTIVation message, that is normally handled
once the PHY completes the process of timeslot re-configuration.
On receipt of subsequent RSL CHANnel ACTIVation messages, in function
dyn_ts_l1_reconnect() we overwrite the preceeding msgb (memleak), by
the most recent one. And once the timeslot re-configuration is done,
only the most recent CHANnel ACTIVation message gets ACKed.
In order to avoid this, let's move the msgb ownership to 'struct
gsm_lchan', so it cannot be overwritten by the CHANnel ACTIVation
message that is related to a different lchan on the same timeslot.
Change-Id: Ia625c2827fca883ea712076706d5ef21ed793ba6
Related: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Fixes: OS#5245
Otherwise after reconnecting some SI are still marked as valid despite
the new BSC conn didn't set them.
Change-Id: I71e2a5cdf4e2e287db7b05df1a165a1e32c958ca
Let's split all lchan and power_control specific stuff into their own headers,
it helps finding out data and operations available related to them.
We already have similar classification in osmo-bsc.
Change-Id: I6424dcbd2e329fc1a516f8886359554ed7e9487e
It makes no sense to transmit load information if the channel is still
not operational. This solves errors messages seen in osmo-bsc.
Related: OS#4872
Change-Id: I7ddda9776158eed0694df9e458f3f91df90bf674
Have a more stable loop with less temporary oscillations at the expense
of increased reaction time.
4 SACCH blocks (P_CON_INTERVAL=2) is the minimum interval to get stable
measurements for the last requested MS Power level. With P_CON_INTERVAL=1,
are also made during a period with stable power being use to transmit,
but the MS Power level used (and announced in MR) is not the last one
requested by the BTS, but the one requested in the previous loop
iteration. This can make the MS and BTS bounce 2 values forth and back,
and create some temporary oscillation.
See osmo-bsc User manual section "Power Control" for more information.
Related: SYS#5371
Change-Id: I91c505447f68714239a4f033d4f06e91893df201
A broken BSC could send a Chan Activation on a TS which has not yet been
enabled (or even configured). This is the case with our TTCN3 tests,
where OML side is currently handled in parallel by an osmo-bsc while
TTCN3 takes care of the RSL side. This can actually be seen as a
malfunctioning BSC, but it was spotted that given this sequence of
events osmo-bts can crash (see ticket below).
Hence, let's NACK any attempt from a BSC to activate an lchan on a
disabled TS.
Related: OS#5249
Change-Id: I9c3b68487c12efc412a057728a561e061560c544
It helps better understanding the code, and will allow handling
situations where for instance a POWERON in in transit while the BTS is
instructed to shutdown, hence a POWEROFF needs to be sent.
Change-Id: Iaf62217ceab7420afa4140cba61e1c2f983c61b4
config.enabled is always true in that state. Hence, those paths can be
securely dropped since only add confusion.
Change-Id: Icf00c52e61ddedd8e32eb37223cea5686005e6a3
The first check in this function ensures that the state is NONE.
Therefore it does not make sense to print it below..
Change-Id: I62ea4117dd5e1eebb8774809134e5cb73774945c
This was colliding with the global "show trx" command introduced a few
years ago, and prevented both command from working.
Change-Id: I57f9515292f7bd906599e2cc277542bfaf3b657b
Related: OS#5080
Each RSL MEASurement RESult message contains a Measurement Number
IE, which is basically a monolithically increasing number. We
shall not increase this counter if for whatever reason the report
has not been sent to the BSC.
Change-Id: I441adb4b202e94ddee8c0b6777849e36ea644b1d
Fixes: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
Fixes: OS#5243
Avoid re-connecting to a new BSC while BTS is in shutting down. All the
FSMs are complex enough to even try to re-start when stopping has not
yet finished...
Change-Id: I1727828a16f4ec8043b00cc6b2e02a4c35f71377
Prior to this patch, the power ramping started when the PHY is
available, but that doesn't necessarily mean the RCARRIER is enabled.
Due to this, it was spotted a situation where BTS bootstrap failed after
PHY turning up, when RSL connection establishment failed. Hence
bts_shutdown_fsm triggered a shutdown while an active power ramping up
was ongoing...
Change-Id: I17208b74ea2649b1bbb717aee0aa355e42b7e860
This may happen if bts_shutdown starts a poweroff procedure while
POWERON was still not sent to the TRX. In this case, we want to go back
to initial closed state to fullfill expected state when BTS is shutdown.
Change-Id: Id660fa1018ef175ab237733b37629c56313c061d
Previous code creating a new line was really a workaround to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and keep using the
same line always (since it can be further configured by libosmo-abis' VTY).
Recent patches to libosmo-abis fixed a bug where e1inp_line_update()
would only work the first time it was called on a e1np_line, and follow
up calls would be no-ops. This fix allows re-configuring and hence
reusing the same line to reconnect to BSC.
Depends: libosmo-abis Change-Id: Iff8092f88726cf238dac2abb99e135ac5864272d
Change-Id: Id7fd3ef81bbc517821def31f1a60f905a0e2fb52
The temporary overpower value that is to be used with FACCH and SACCH is
transferred using a proprietary RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP). The
parsed value is then stored in lchan->bs_acch_overpower_db so that it
can be used.
Change-Id: I426c2510865c4a986c68f2027cc676aaac0d8a4c
Related: SYS#5319
Only once we receive the Measurement Result on L3 from MS we are able to
find out whether DTXu was used, and hence whether SUB or FULL
measurement set should be used.
Let's move all control loops there to have them in one place together,
and have it at a similar level where it would lay if it was to be
implemented in the BSC.
Related: SYS#4917
Change-Id: Ic152473577ff7c33d30b3f4ee7e321fcb523f723
This is a preparation commit in order to move power loops up in the
stack in order to have DTXu information available, in order to decide
whether SUB or FULL ul measurements should be used in the MS Power
Control Loop.
Function rsl_tx_meas_res() is stripped from code changing state, and it
simply encodes content and transmits the message.
Change-Id: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
Recent commit added code to reset trx_provision_fsm state fields in orer
to support re-using the FSM once BTS is reconnected to a BSC.
However, some values being reset there are not set up when reconnecting
to the BSC, but rather configured through VTY at startup. Hence those
values should be kept.
Fixes: 32b51eca7d
Change-Id: I5c31241327b98386c313cd9377cf76c009456105
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
When I introduced this branch in change [1], I was under assumption
that PDCHs never have an associated 'struct gsm_lchan'. This is
incorrect: the association actually happens during PDCH activation,
i.e. when osmo-pcu establishes connection over the PCUIF.
Enforcing attenuation of 0 dB for other channel types makes no sense.
[1] I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Change-Id: I77a839725f22be1be4a025f579c4c9ccdfb53460
There is no need to log channel activation / deactivation messages
as LOGL_NOTICE - this is a normal event requiring no attention.
Change-Id: I7765fecb7f7ec67c8f96e91c378626e21e48c71d
Thanks to [1], there is no need to patch chan_nr for PDCH anymore.
The upper layers are now expected to use the correct values.
[1] I01680140c7201bf5284b278bceaea8ae01c122b2
Change-Id: I26eb2081eddb4ce900a7867897bc69c3f77dbd73
Related: OS#5238
The ip.access style dynamic timeslots are a bit special in a way that
on the A-bis/RSL we always use the Channel Number value of TCH/F,
even in PDCH mode. This is why gsm_lchan2chan_nr() would always
return values corresponding to TCH/F for TCH/F_PDCH.
This behavior is only acceptable in the context of RSL messages, while
other parts of the code base may not work properly due to this trick.
A good example is the scheduler in osmo-bts-trx, where we have to
patch Channel Number value to make channel activation work.
DPCU INFO pcu_sock.c:853 Activate request received: TRX=0 TS=5
DL1C INFO l1sap.c:2043 (bts=0,trx=0,ts=5,ss=0) Activating channel TCH/F on TS5
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PDTCH
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PTCCH
In the code branch responsible for channel deactivation, we somehow
forgot to add the same workaround, so deactivation does not work:
DL1C INFO l1sap.c:2076 (bts=0,trx=0,ts=5,ss=0) Deactivating channel TCH/F on TS5
DTRX INFO trx_if.c:255 phy0.0: Enqueuing TRX control command 'CMD NOHANDOVER 5 0'
DRSL NOTICE rsl.c:1286 (bts=0,trx=0,ts=5,ss=0) (bts=0,trx=0,ts=5,ss=0) not sending REL ACK
Because of that, TCH/F_PDCH timeslots actually remain active after
deactivation, so the scheduler keeps producing L1SAP DATA.ind.
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583426/1194/00/29/14 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583430/1194/04/33/18 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
Instead of patching Channel Number in various places, let's rather
make the RSL specific behavior configurable by having two variants
of gsm_lchan2chan_nr().
Change-Id: I01680140c7201bf5284b278bceaea8ae01c122b2
Fixes: OS#5238
LOGPLCHAN() prepends the contextual information for us, there
is no need to print trx->nr again. Take a chance to apply
some additional cosmetic changes, like fixing capital letter.
Change-Id: Ia199d584c937eef4118c99af4523fd91b2e46107
In functions responsible for Downlink burst scheduling, it may happen
that the buffer, containing a complete set of to be transmitted bursts,
a) is not yet allocated or b) was de-allocated intentionally. In this
case, we return early to avoid NULL pointer dereference. The returned
value is then checked against 0 in _sched_dl_burst().
Returning 0 makes _sched_dl_burst() apply per-burst attenuation, as
well as the A5/x encryption (if enabled). And this makes no sense
in either of the cases mentioned above.
Moreover, in the BCCH power reduction mode, this causes some bursts
(bid > 0) of idle PDTCH/PTCCH blocks to be transmitted at full power,
breaking the energy saving feature.
Change-Id: I18aa73cc950fdfac030b63f7a434a71b4596095d
Related: SYS#4919
osmo-bts-omldummy is known to be specially in the sense that it has no
phy. This should ideally be changed to have some dummy object, but so
far that's how it is. A recent commit checking the phy's forgot about
the fact that BTS model has no phy. Let's fix it.
Fixes: 4ddc37ce71
Change-Id: Iba7873530aac74b3bf799819890641196dacf170
Previous code creating a new line was really a workaroudn to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and erase +
re-create it every time.
Recent patches to libosmo-abis fixed a crash happening when refcount
being 0 and destroying the object (object was not removed from a global
llist).
Depends: libosmo-abis Change-Id I1314d6b917ecb622994507475eb894e649a1a2ad
Change-Id: Ic37ae5bf657247e8cce99182c40d9adf890a5e41
Commit below (see "Fixes" section) wrongly erased the code re-introduced
in this commit, due to not spotting different between "oml_link" and
"osmo_link". This commit is hence a revert of such commit, updated to
current code.
Fixes: c2ba34d9c1
Change-Id: Id436116e5cd0bec024b2f9943fbff8d0bdc956ac
This function is only called during sign_link_up() e1inp callback, hence
only the link!=NULL condition (UP) is ever executed. Let's drop the DOWN
path and make it a function only used to trigger events when link
becomes up, similar to what bts_link_estab() does with OML.
Here it becomes clear the NM_EV_RSL_DOWN was never sent. It's not much
of an issue though since it would only make transition RCARRIER/BBTRANSC
Enabled->DisabledOffline. However, since due to libosmo-abis limitation
we receive a sign_link_down() for the entire line when 1 of its links
goes down, we don't care much since we go for shutdown of the entire BTS
anyway. Ideally, libosmo-abis would support simply telling us 1 of the
links in the line went down and if it was not OML and not RSL TRX==C0,
then we could keep on running and simply disable the related TRX.
Change-Id: Iac553c68339c0da32fd313676995747eb4344087
This feature is not yet used by any bts_shutdown_fsm caller, but will be
used in the future when Abis link goes down.
Change-Id: I5dc282fdbcf862067be326e72b6183dd544222ae
Since recently we support shutting down phys when BTS goes into shutdown
mode. Let's make sure they are opened again when we connect again to the
BSC.
Change-Id: Ia1df6f4a1e0e6daeffe7303d518776a04b023930
This step is required while turning off the BTS without killing the
process. Right now only osmo-bts-trx supports this feature, so this
function is only available and used by osmo-bts-trx.
Later on, when the feature is support more generally, we can move call
to this function to common place like bts_shutdown_fsm or alike.
Change-Id: I3253112700a31b85db82dc7ccadec8542bac745e
Once the TRXC link is available, we can signal SW_ACT which will
transit rcarrier and bbtransc NM FSMs to Disabled Offline and announce
availability to be configured to the BSC through transmission of
Software Activated Report.
Change-Id: I6e62ec2fdd4cae58b52d83fa851552f7ed51c821
In OML, if Set Attributes comes first for Channel object and then for
BTS object, BSIC will still not be set. Hence, when applying Channel
(TS) specific TSC, the code would compare against an unset value,
enabling use of TRXC extensions (which osmo-trx doesn't support)
without need for it, since actually the TSC of the TS matches the BSIC
of the BTS once both are set.
In order to fix it, don't check for the BSIC when receiving the OML
messages, but rather later when we apply the settings to the the lower
layers once trx_provision_fsm allows for it.
Fixes: 3c1151f945
Change-Id: I49fc7e35acb44ecc4f37ae71acd4c684248548e7
This way the PCU can signal idle RLCMAC blocks (no transmission
required) to the BTS, which can then send dummy/fill blocks aplying
power reduction as needed by TRX.
The block with len=0 is submitted to lower layers up to the scheduler,
which will finally drop it in trx_sched_ph_data_req().
Change-Id: I734c66e236bf3e2015a4571ea1fd84849a9ef02c
Related: SYS#4919
This way we provide an effective way to disable C/I based decision
taking in the MS Power Control Loop. With this set up, MS Power Level is
decided only based on RxLev. This allows for working setup in following
scenarios:
* BTS L1 not passing proper C/I values to upper layers (eg. TRXDv0).
* User not willing to spend time configuring proper C/I levels for each
channel type.
Related: SYS#4917
Change-Id: Ibd10eb96a5d072d5c19f7449a8b11e64aad1cd4c
Get rid of this helper function, which is a remain of past epochs
(pre-FSM). In the current uses, there's only 2 real cases: the "if" path
upon SET BTS ATTR received (and even that one should be moved as per
what the code comment states), and the one happening when the TRX is
closed.
it really makes no sense to DISABLE the TRX as a result of SET BTS ATTR.
Change-Id: I48adfeecd722684152c589bcba827079b0a78c3a
In oml_rx_set_bts_attr, arfcn for C0 is assigned from NM_ATT_BCCH_ARFCN.
The rest of the TRX get their arfcn from oml_rx_set_radio_attr()
NM_ATT_ARFCN_LIST.
Change-Id: I8aa9652622107fe0a707b2cbcbe8be6c71e19087
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
There's no real use for this queue. If the link is gone, it makes no
sense to keep old messages. Instead, BTS should generate new messages
sharing current state when link becomes established (it actually does
so already).
Change-Id: Iecd3c7cb96f5fff3b4c7e04c74e031df0f7a6987
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
Do not exit if all BSCs in the list fail to connect, keep trying
forever. This commit still doesn't change the logic after BTS has
successfully connected to a BSC. In that situation, if the link goes
down, BTS will exit in order to reset all state and let the user/system
restart it.
Related: SYS#4971
Change-Id: I67bba3b7e2d9d62b98a59a74987ae55206a3ec51
The pointer was used as "struct bsc_oml_host" sometimes, and other times
as "struct llist_head". It just worked because bsc_oml_host->list is the
first item in the script. The code was really confusing, also because
the bts list of items has a name really similar to the one currently
assigned. Let's rename the currently assigned address to "current_bsc",
store it always as "struct bsc_oml_host*" and finally use llist_entry
helpers when needed.
The related code is also moved to a helper function to enclose there the
logic to get next BSC in list. This change actually changes the logic
where a remote address is removed from VTY, since now the next address
in list is picked at the time, and later when reconnecting the list is
forwarded another time, meaning one address will be skipped.
This could be considered a bug, but this situation is really special
and anyway the entire logic will be changed in new commits where we'll
keep reconnecting in loop without exiting when reaching the end of the
list, so we are fine with it. Think of this commit as a preparation
commit for next ones.
Change-Id: I3cc8a4148b3d63bc185b72dab8108105a6644910
This clarifies the different states and transitions between them:
OML LINK UP: CONNECTING->CONNECTED
ANY LINK DOWN: CONNECTING->CONNECTING, CONNECTED->FAILED
In follow up commits, support to reconnect instead of exit after the BTS
has already connected will be added, so only the last transition needs
to be changed.
Related: SYS#4971
Change-Id: I43e83b1b04fbaa1f87818c096e6ad3920801b1f6
This test showcases the current issue where the loop keeps bouncing
between 2 good MS Power Level values due to the loop "accepting" and
"reporting back" the previously considered good MS Power Level
announced/used by the MS. Hence, upon report back from the network, the
MS will switch to this new MS Power Level, and same thing will ocurr
over and over.
Related: SYS#4917
Change-Id: I16ed7fe8a123b99008e0c041d2f3e4232057d55c
This should simply not happen. If other event is received, something is
terribly wrong, so we should exit immediately instead of silently
failing.
Change-Id: I5f4953be735f526bb8b926979233b3c26ba67ce9
CONNECTING state comes first in logical order of states (as properly
seen in enum of states), however, the FSM struct definition and state
action functions are swapped. Let's put them in order.
Change-Id: I0cae561926b460dc5882390db969b7c925903e5d
abis_init() sets "g_bts = bts;", hence bts object is the same as g_bts
(since we only have 1 BTS object in osmo-bts). As a result, dropping
checking first bts->... and later g_bts->... makes no sense: the later
condition will always be false.
Change-Id: I5018199221fb3c3329a59d0b91e827f077cef85d
Similar to what is already provided for power control loops. However,
there's no existing way to communicate TA control parameters from the
BSC to the BTS, so implement them locally in BTS vty.
Related: SYS#5371
Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
TS 45.008 section 4.7.1:
"""
Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS
shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a
range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to
the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a
time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes
place or not.
"""
Since the reported MS_PWR in L1 SACCH Header is, according to specs, the
one used for the last block of the previous SACCH period, it becomes
clear the first SACCH block after a requested MS Power Level change by
the network may contain mismatches between the announced MS_PWR by the
MS and the measured Rxlev/RxQual. Hence, let's better use a
P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second
SACCH block.
Change-Id: If6cb8945645a2031f2b2ee65d9b9f51e75cd9af1
Related: SYS#5371
As per 3GPP TS 45.010 sec 5.6.3 Delay assessment error:
"""
the delay shall be assessed in such a way that the assessment error
(due to noise and interference) is less than 1/2 normal symbol periods
for stationary MS. For MS moving at a speed up to 500 km/h the additional
error shall be less than 1/4 normal symbol period.
"""
Hence, required TA loop calculation should take into account an error of
up to 1/2 + 1/4 = 75% of a symbol. By changing the threshold variable
to that percentage we make sure we take into account bigger deviations
and update TA accordingly.
Related: SYS#5371
Change-Id: I4c5825df4291d3851a113027abf7566de343a190
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is
the value used over previous measurement period. Hence, we need to feed
the algo with the measurements taken over that same period.
Related: SYS#4917
Change-Id: I00852cb37a3613606e37476c169f5a32d6b5d75e
Field is renamed to look similar to similar fields in power control
loop. This is a preparation commit, next one will add functionality to
skip SACCH blocksi (P_CON_INTERVAL).
Related: SYS#5371
Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
From TS 45.010 5.6.1 (delay tracking for circuit switched channels):
"""
Restricting the change in timing advance to 1 symbol period at a time
gives the simplest implementation of the BTS. However the BTS may use
a larger change than this but great care must then be used in the BTS design.
"""
In general 1 TA at a time (every 480ms of SACCH block) should be enough,
since section 5.6.3 states:
"""
The control loop for the timing advance shall be implemented in such a way that it will cope with MSs moving at a
speed up to 500 km/h
"""
Which is ~140 m/s, and 1 TA step around 500m, so most of the time we
should be save and no steps of more than 1 TA should be required.
However, unlikely changes from reflected to direct signal or vice versa
could produce higher increments, so let's increase the maximum step size
allowed to 2 in order to give more room.
Change-Id: I9e48faabf3090588233e274b2b39065cf85fbec7
First step improving and reworking TA loop:
Move trigger of the loop to similar place done by BS/MS Power Control
Loop, that is, upon receivial of UL SACCH block, which contains
information about the TA used to transmit the block encode in L1SACCH
Header. Hence, from computed received TOA and TA used when transmitting
from the MS, we can infer the desired TA to be used by the MS, which
will send back to it later during DL SACCH block.
The values taken are actually the ones calculated for the previous SACCH
block and stored in lchan->meas.ms_toa256. That's because L1SACCH
contains the TA used for the previous reporting period, similarly to
what's specified for MS Power Control loop (TS 45.008 sec 4.2):
"""
The MS shall confirm the power control level that it is currently employing
in the SACCH L1 header on each uplink channel. The indicated value shall
be the power control level actually used by the mobile for the last burst
of the previous SACCH period.
"""
(The reader may observe that currently this is not properly done for MS
Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.)
This new method also permits changing TA quicker, since we have more
confidence that the TA we request is aligned with the one used to
transmit, and we don't simply increment/decrement based on the value we
request to transmit.
Related: SYS#5371
Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
Tests have shown that even a delay of 0, i.e. a simple defer until the
next select() loop, makes the difference from failing to working early
IA. So set the default to 0, achieving such defer.
Related: SYS#5559
Change-Id: I95365649edd51114bcf6028f0dc3bbe4186f96d2
During live testing, it has become apparent that some IMM ASS still fail
when sending the RR IMM ASS directly upon the target channel becoming
active.
Add a bit of delay after activation, to give some time for the channel
to light up for the MS. Default is 50ms.
Related: OS#5559
Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
The bug showed up in previous commit and is fixed in this commit. It can
be seen how rounding error is carried over time in the average
measurement, and affects final values.
Change-Id: I680d1c94bd4bae179b14b26662a819fa1462a5c8
Before this comits, averaging and delta calculation was done in RSSI,
but stored the averaging cached state in variables named "rxlev", which
was really confusing. Let's keeping averaging and delta calculations
based on RxLevels.
Some of the tests change results due to test passing RSSI -45, which is
an invalid Rxlev (only up to -47 is supported).
Others fail due to an unrelated bug showing up now. Basically the averaging algo
is doing rounding the wrong way when downscaling the values. It will be
fixed in a follow-up commit.
Change-Id: I4cff8394f22b5d47789163051364ff594b2bcd74
If RxQual is considered good enough, attenuation can be increased in
order to lower overall cross-channel noise among different MS.
Change-Id: Ie97898980acd152de15f6b4b619d492048855ef4
params->rxqual_meas.upper_thresh is left unchecked in
lchan_bs_pwr_ctrl() on this commit on purpose, to keep this
commit with old behavior wrt to algo logic.
Change-Id: If7e3987df89d680cfa443195ab2f225681d0e6cf
This commit reworks the code in function lchan_bs_pwr_ctrl()
and logging to look similar to that of lchan_ms_pwr_ctrl(), so that
reader can easily spot similarities between both and add simillar
features more easily.
This commit is also a preparation to add EWMA avg support for RxQual
measurements. Logging is also reworked now to look similar to that of MS
Power Control Loop, because having several parameters driving the algo
(RxLev and RxQual), it becomes more suitable to log all of them together instead
of intermediate info only aplicable to one param such as "delta".
Change-Id: Ida76b55f0da722135eb61ed06ea2b3a1862df600
This commit extends existing MS Power Control Loop algorithm to take
into account computed C/I values on the UL, received from MS. The
related C/I parameters used by the algorithm are configured at and
provided by the BSC, which transmits them to the BTS similar to already
existing parameters.
Using C/I instead of existing RxQual is preferred due to extended
granularity of C/I (bigger range than RxQual's 0-7).
Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance"
Table 10.3) provides detailed information about expected target values,
even different values for different channel types. Hence, it was decided
to support setting different MS Power Parameters for different channel
types.
These MS Power Parameters are Osmocom specific, ie. supported only by
newish versions of osmo-bts. Older versions of osmo-bts should ignore
the new IEs added just fine. The new IEs containing the MS POwer
Parameters are not send for non osmo-bts BTSs, hence this commit is
secure with regards to running osmo-bsc against an ip.access BTS such
as nanoBTS.
Related: SYS#4917
Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca
Change-Id: I5dfd8ff9ab6b499646498b507624758dcc160fb6
All generated RTP that originates from the BTS relates to uplink. When
generating AMR BAD frame RTP packets, we must use ul_cmr/ul_ft and not
dl_cmr/dl_ft.
Change-Id: Ifa009819791cf7df2dd8201f442b0dae06f622a4
Related: SYS#5549
The AMR transmission phase directly depends on the frame number. The
transmission phase is used to tell if a received AMR frame contains a
CMI (frame type that is currently used) or CMR (frame type that the
receiver should use) codec identifier. The formulas in the present
implementation seem to be correct but they do not reflect the numbers in
the spec very well, nor do they have unit-tests. Lets replace them with
more readble functions and test those functions with unit-tests.
Change-Id: I94a934a6b3b397b4cd0e9da3577325de58814335
Related: SYS#5549
CMR and FT are updated each time an AMR voice frame is received from the
radio interface. The transmission phase decides whether the voice frame
contains CMR or FT. The code follows the transmission phase and keeps
ul_cmr and ul_ft up to date.
In contrast to the AMR frames on the radio interface, an AMR RTP packet
always contains the CMR and the FT value.
When generating the RTP payloed, The present implementation uses the CMR
in the position where the FT should be and the FT is ignored. This is not
correct.
Change-Id: I6bb10ff3c76f67b9830787497653b546cf27fe8e
Related: SYS#5549
struct ipac_preproc_cfg seems to suggest that there may be up to 3 IEs
in some cases:
"struct ipac_preproc_ave_cfg ms_ave_cfg[3];"
Change-Id: I02633713eb557ee52e790a239f7b13b8c5b2b3bd
Fixes: 9238c3549d
Related: SYS#4918
When generating GSMTAP, we are already suppressing generation for
fill frames on PCH and AGCH. Let's expand that also to dedicated
channels SDCCH, TCH/F and TCH/H. The fill frames just clog up the
logs without providing much benefit.
SACCH is still being logged, as it contains SI or MEAS REP, so every
active channel still sees GSMTAP traffic every 480ms (SACCH interval).
Change-Id: I0dd37d8848eb0379f84d15f5f006142b16823c6a
If for whatever reason the transmit queue of a TCH/{F,H} contains
neither speech frames nor signalling blocks, osmo-bts-trx would
currently transmit garbage. Of course, this causes decoding
errors at the MS side.
Ideally, we should employ an ECU (Error Concealment Unit) for the
given codec in use. However, a simpler solution is to transmit
dummy LAPDm frames over FACCH. This is what e.g. nanoBTS does.
Change-Id: I868afecbcb6890f40c8f146e3ce00e836b794dd3
Related: OS#4823
We have two osmocom specific timers used in the BTS, X1 and X2. Expose
those on the VTY configuration, as timer group 'bts'.
This prepares for a subsequent patch, where I would like to add another
configurable timer. This provides the basic infrastructure for that.
Related: SYS#5559
Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
This is not as trivial as with OsmoBSC or OsmoMSC, because normally the
osmo-bts process exits right away when there is no BSC. Hence add
--vty-test option to main.
Use 'osmo-bts-virtual --vty-test' for testing. The other BTS models
require dependencies / configure switches to be built.
Essentially copied from osmo-bsc.git:
configure.ac: add --enable-external-tests
tests/Makefile.am: add 'vty-test' target
Add osmo-bts.vty, some trivial VTY node testing.
This prepares for adding VTY tests for T timer configuration added in a
subsequent patch.
Related: SYS#5559
Change-Id: I730daf548a3a9bb116aa8b6d5772ca9af0ada08f
When an Immediate Assignment comes in targeting an lchan that is not yet
active, then hold back the RR Immediate Assignment until the channel
becomes active.
This allows the BSC to send the Immediate Assignment before first
waiting for the Channel Activation ACK, saving one Abis roundtrip, and
helping avoid double allocation on high latency Abis links.
Related: SYS#5559
Related: I56c25cde152040fb66bdba44399bd37671ae3df2 (osmo-bsc)
Related: Ifb2c62431a91dafa6116b5d6b9410930f00a6e18 (osmo-ttcn3-hacks)
Change-Id: Ie52765b238b01f22fb327fe12327fbf10abcad4c
At the moment we can only configure a single BSC in the BTS
configuration. This also means that if this single BSC fails for some
reason the BTS has no alternate BSC to connect to. Lets extend the
remote-ip parameter so that it can be used multiple times so that an
operater can configure any number of BSCs that are tried one after
another during BTS startup.
Change-Id: I205f68a3a7f35fee4c38a7cfba2b014237df2727
Related: SYS#4971
Make gcc 11.1.0 false positivies happy
After my system's gcc was upgraded, I get false positivies in a couple
places. Let's initialize those to make gcc happy.
"""
//git/osmo-bts/src/common/vty.c: In function ‘lchan_summary’:
//git/osmo-bts/src/common/vty.c:1881:23: error: ‘ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1881 | lchan = &ts->lchan[lchan_nr];
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~
//git/osmo-bts/src/common/vty.c:1869:20: error: ‘trx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1869 | ts = &trx->ts[ts_nr];
| ~~~^~~~~~~~~~~~~~~~~
//git/osmo-bts/src/common/vty.c:1852:34: error: ‘bts’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
1852 | if (trx_nr >= bts->num_trx) {
"""
Change-Id: I93477142a5a4b3f3829b7398d6e564c127263596
When the paging queue is filled up to a critical level, pagings from the
PCU should be dropped as each immediate assignment paging from the PCU
is worth 4 normal CS pagings. Also the PCU may still issue pagings if the
paginging queue is already full and CS pagings are dropped. In a
congestion situation it is more important to get the CS rather than PS
pagings through.
Change-Id: I30f97672d7a0c369c4a656e878ab8cbbd83e31ea
Related: SYS#5306
Instead of using tlvp_val16_unal() and then doing ntohs() here
and there, convert the remote port to the host byte order once.
Change-Id: Id883a976a03fd3022ed9d66f703b01244df2d9db
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
BS Power Control is not allowed on the BCCH/CCCH carrier, unless
the BTS is operating in the BCCH carrier power reduction mode.
Allow constrained BS power reduction (up to 6 dB) on active logical
channels iff BCCH carrier power reduction mode is enabled.
Change-Id: I3299b6cdd230d3767321c3d6c64d468b7f5e1d02
Related: SYS#4919, SYS#4918
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, in the recent 3GPP TS 45.008 there is a feature called
'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
The power reduction operation can be controlled by the BSC by
sending BS POWER CONTROL on the A-bis/RSL with the Channel Number
IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the
transmission power on inactive timeslots of the BCCH carrier.
This is a non-standard, Osmocom specific extension, so indicate
support of this feature to the BSC in the feature vector. Also
add a VTY command to allow enabling/disabling the power reduction
locally. Add some signalling notes to the A-bis/RSL manual.
For more details, see 3GPP TS 45.008, section 7.1.
Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716
Related: SYS#4919
This is required for ttcn3-bsc-test, see change [1].
Change-Id: I765d5e38cb0746e0458773abf3717ee9bf1cb7d1
Related: [1] I084f7736cd7d09b68ed49f8ba52a14de928d4c01
Related: SYS#4919
This reverts commit cd30a40be1.
As a part of SYS#4919 "BTS energy saving", we want to support
constrained (up to 6 dB) BS power control on BCCH carriers.
Change-Id: I0d2b48c4b2af2d8e94f4ad02fa4774dbd0a0a654
Related: SYS#4919
This new extension protocol is used to forward Osmocom PCUIF messages
BSC<->BTS<->PCU.
It will be sent re-using the IPA multiplex of the OML link between
BSC and BTS. BTS is responsible for forwarding the message over the unix
socket to the PCU.
PCUIF existing RX path needs to be reworked in order to accept
variable-size messages, in order to be able to transparently forward
messages without knowing about them (the new container message is
variable-length).
Related: SYS#5303
Change-Id: I73fdb17107494ade9263a62d1f729e67303fce87
I introduced this regression in [1] during a massive refactoring.
Basically, I copy-pasted a chunk from trx_sched_ph_data_req(), but
forgot to change the union field. This broke voice calls, because
all TCH.req primitives would be enqueued to wrong timeslot.
Change-Id: If841e6ac40a3c6344c304ab970755d6a2d292156
Fixes: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
The PDCH multiframe contains 48 data slots, 2 PTCCH slots, and
2 IDLE slots. The later two can be used for the interference
measurements, since the UEs shall not transmit on them.
bts_report_interf_meas() is called every 104 TDMA frames, what
corresponds to 2 PDCH multiframe periods. Report interference
levels on PDCH timeslots from this function.
Change-Id: I56f83db5264c246ec1b4b8a973105a4fc09931fb
Related: SYS#5313, OS#1569
We already do the intereference measurements on inactive logical
channels. For the active channels we can still use the IDLE
slots, on which the UEs shall not transmit Uplink bursts.
Change-Id: Ic3030dba5eb223177298aa4e43559a93dc3d1392
Related: SYS#5313, OS#1569
Neither we expect any Uplink bursts on IDLE channels, nor we need
to send any Downlink bursts. Automatic activation of TRXC_IDLE
channels does not make sense.
Change-Id: Ifade0eab0605154196322ff20b1b3a44495f8a2e
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped
to inactive logical channels as interference. Average the RSSI
values on the fly using a sliding average with constant a=0.5.
Report averaged values for each logical channel every 104 TDMA
frames (SACCH period) by calling gsm_lchan_interf_meas_push().
Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5
Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c
Related: SYS#5313, OS#1569
With the new ordering, all TRXC_* values starting from TRXC_TCHF
belong to dedicated channels. This is useful for the interference
reporting logic, where we're not interested in broadcast channels.
Change-Id: I7148f4d0bd1abbfe309bc5477e32a56d884533ea
Related: SYS#5313, OS#1569
This change implements general interference averaging logic for
the higher layers. In l1sap_info_time_ind(), where we receive
TDMA time updates from BTS model, call rsl_tx_rf_res() for each
transceiver according to the interval defined by the Intave
parameter received from the BSC. In rsl_tx_rf_res() perform
the actual averaging for each inactive logical channel, and
then send everything to the BSC over the A-bis/RSL.
The BTS model specific code needs to report the measurements
for each logical channel every 104 TDMA frames (SACCH period)
by calling gsm_lchan_interf_meas_push().
Change-Id: Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Looks like this part of the code has never been tested. The old
code would dereference the same value in the loop and assign it
to all members in array 'bts->interference.boundary'.
Change-Id: I7f83d8e6eb6cc19e3e9529ba06617a902de23e35
Related: SYS#5313, OS#1569
OsmoPCU will need this SI2 in order to gain knowledge of the BCCH
Frequency List being broadcasted, in order to build a per-MS specific
Neighbour List using NC_FREQUENCY_LIST bits in Packet Measurement Order.
Related: SYS#5303
Change-Id: If70c64f941f621a9a68aef2c846639b5c7f2f74b
In cfg_trx_phy_cmd(), use phy_instance_link_to_trx() and ensure
that a PHY instance can be bound to a transceiver only once.
Change-Id: I132e08fc496abef278b94254cebfac7a4285a7c2
Thanks to [1], it's now possible to associate a human-readable
name with a rate counter group. Before this API, we had to use
weird index values for each timeslot, and with introduction
of the shadow timeslots the situation got even worse.
Change-Id: Ie872ab37661fa5d44f219f59c7daaa1033113289
Depends: [1] I0dc510783dd9ae8436dae8005a7b3330e80d36f3
Related: SYS#4895, OS#4941
The timeslot number ts->nr is set in gsm_bts_trx_alloc() and can
never be greater than 7. Regarding the physical channel type
returned by ts_pchan(), it's also unlikely to be greater than
_GSM_PCHAN_MAX.
Change-Id: I6d20d7cba49cc8b6d1dc2192598ca372b7d2c5bf
This function is called during the OML bootstrapping, and also
when a dynamic timeslot switches between PDCH and TCH/{F,H}.
In the later case, after switching from TCH/{F,H} to PDCH, some
lchans might still have the old type assigned.
Let's ensure that all logical channels are properly updated.
Change-Id: I44726f2bfb979c2fa2f5f30c5b11700cf4b3399d
Related: SYS#5313, OS#1569
This regression was introduced (by me) in [1] and broke CCCH.
Change-Id: I403ad06574a8505b69dd06781f7fe0f7cabf416f
Fixes: [1] I1c5a033e89d9ca5fb01ebe9ffb521fd67d159bee
Related: SYS#4895, OS#4941
Using the normal arithmetic for TDMA frame numbers may result
in getting wrong values. Consider the following situation:
'info_time_ind->fn' is 0 (beginning of period)
'bts->gsm_time.fn' is 2715647 (end of period)
With these input values the following expression:
info_time_ind->fn - bts->gsm_time.fn
will be equal to:
0 - 2715647 or -2715647
In this case osmo-bts does not log an error, because:
if (-2715647 > 0) // is false
As a consequence, we do not increment number of RACH slots that
have passed by since the last time indication:
for (i = 0; i < -2715647; i++) // is false
This is why we introduced GSM_TDMA_FN_{SUB,SUM,DIFF,INC} API.
Change-Id: I6168dd75daea50bbe2e19338e637185ac9ac87ef
There is no GSM_PCHAN_TCH_F{_TCH_H}_PDCH in trx_sched_multiframes[],
so find_sched_mframe_idx() would always return -1 for these. Fix
this by using ts_pchan(), which returns currently active pchan type.
Change-Id: Ia5e337e897b595e7de6e504664c969b583cc02a1
Starting from TRXDv2 [1], trx_if_send_burst() would keep batching
PDUs to the static buffer, unless it's called with br = NULL, so
we cannot dereference br in the logging statement.
Of course, we could also store TDMA frame number in a static
variable, but I don't think it's worth it just for logging.
Change-Id: I4a361777fc40bdedcebbe54df6274bc5573f77a8
Fixes: [1] I9b4cc8e10cd683b28d22e32890569484cd20372d
Fixes: CID#236232
This is an Osmocom specific RSL IE that, if present, takes
precedence over the values indicated via the A-bis/OML.
Change-Id: I717e5b2a6ca5b4faeaab9cae4bb971907945871b
Related: SYS#4895, OS#4941
Each timeslot can have its own Training Sequence Code value, which
may optionally be included in the NM_MT_SET_CHAN_ATTR message sent
over the A-bis/OML. If it's not present, then the TSC value for a
timeslot is derived from the BCC part of BSIC, which is always
included in the NM_MT_SET_BTS_ATTR message.
On the TRXC interface, the BTS global TSC value is indicated to the
transceiver using either of the 'SETTSC' or 'SETBSIC' commands.
The transceiver then applies this value for all timeslots by default,
however it can be redefined for each timeslot individually using
additional arguments of the 'SETSLOT' command (see section 25.2.4.1
in the user manual [1] for more details).
Currently, trx_set_ts_as_pchan() sends TRX_PROV_EV_CFG_TSC to the
transceiver provisioning FSM, together with the per-timeslot TSC
value. This event causes the FSM to modify the global TSC value,
that is going to be or has already been sent to the transceiver.
This is wrong, the global TSC value shall not be overwritten.
Remove the TRX_PROV_EV_CFG_TSC, and include per-timeslot Training
Sequence Code and Set in the data structure that gets passed together
with the TRX_PROV_EV_CFG_TS instead. Implement handling of the
optional per-timeslot TSC in trx_if_cmd_setslot().
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: Idc5796151e3e83f42d60c2d4cb7c35890d76a7f5
Related: SYS#4895, OS#4941
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
The model name when used when abis_open() is called is sysmoBTS, since
we recently decided to deprecate the type name "sysmobts" in osmo-bsc we
might consider the same thing here.
Change-Id: I3c61d92f5527ae0145316b5ff92660f8b467a8dc
Ensure that we check the PHY capabilities in both cases:
* RSL CHANnel ACTIVation, and
* RSL CHANnel MODE MODIFY,
by calling bts_supports_cm() from rsl_handle_chan_mod_ie().
Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode',
so we can handle VAMOS enabled channel modes and CSD later on.
Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91
Related: SYS#5315, OS#4940
For some reason, handling of the Channel Identification IE was done
in l1sap_chan_act(). This function is being called on reciept
of the CHANnel ACTIVation message, but not on MODE MODIFY.
Change-Id: I07f95e69e6230a1daca62cc0a7c64954f191fa8a
Related: SYS#5315, OS#4940
This change implements TRXD PDU batching approach b), which is described
in section 25.3.4 of the user manual [1]. This approach is quite easy
to implement on the transceiver side, so we can enable it by default.
.Example: datagram structure for combination b)
----
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
----
Other PDU batching approaches can be introduced later.
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: I9b4cc8e10cd683b28d22e32890569484cd20372d
Related: SYS#4895, OS#4941
The path to the temperature sensor was wrong which
results in the SysmoBTS manager always considering
that the state is critical and hence powering OFF
the PA on startup. (with the default config)
As a further side-effect, the temperatures were not
available in the vty 'show manager' command.
Redacted log previous to this patch:
sysmobts_misc.c:128 Error reading temperature
sysmobts_mgr_2050.c:323 Going to enable the PA.
sysmobts_mgr_temp.c:252 Failed to read the digital temperature. rc=-1
sysmobts_mgr_temp.c:267 Failed to read the RF temperature. rc=-1
sysmobts_mgr_temp.c:203 Moving from state NORMAL to CRITICAL.
sysmobts_mgr_temp.c:185 System has reached critical warning.
sysmobts_mgr_temp.c:236 OML alert sent: 0
and in the vty:
Temperature control state: CRITICAL
Current Temperatures
Digital: -0.001000 Celsius
RF: -0.001000 Celsius
With this patch we correctly enable the PA and now can show in the vty:
Temperature control state: NORMAL
Current Temperatures
Digital: 39.000000 Celsius
RF: 35.125000 Celsius
Change-Id: Iac8e9a866ad6326874af91bd12a981f39a9a24c7
In [1] I forgot to update tx_fcch_fn(), where we assume that the
burst buffer is already zero-initialized and do not call memset().
This results in sending dummy bursts on FCCH (instead of zeros).
Change-Id: I491b3b5702b3cfca45c12c002b41e60c629b05b9
Fixes: [1] Iec78989517865b3275a9784d1042a5ebd1d2815f
Currently, in bts_sched_fn() we send a Downlink burst to the PHY
immediately after calling the associated logical channel handler.
Together with the obvious performance advantages, this approach
imposes some serious limitations. The code has already become
quite complex with the introduction of the baseband frequency
hopping, and now it's not possible anymore to extend it further.
TRXD PDU batching, which is essential for VAMOS implementation,
requires us to make the scheduler more flexible at the expense of
increased memory consumption and additional CPU cycles. This patch
splits up Downlink burst scheduling into 3 main steps:
1. bts_sched_init_buffers(): initialization of per-TRX Downlink
burst buffers allocated by phy_instance_create(). For C0/TRX0
all timeslots are pre-initialized with dummy burst.
2. bts_sched_fn(): generating burst bits for all active lchans.
3. bts_sched_flush_buffers(): sending everything to the PHY.
This approach allows us to a) get rid of the ugly tail in bts_sched_fn()
that was responsible for sending dummy bursts on C0/TRX0; b) implement
the PDU batching and have several variants of bts_sched_flush_buffers()
providing the alternative batching approaches later on; c) implement
PDU merging for the upcoming shadow transceivers.
Change-Id: Iec78989517865b3275a9784d1042a5ebd1d2815f
Related: SYS#4895, OS#4941
BCC takes 3 LSB bits of the BSIC, so we should apply 0b111 or 0x07.
The BSIC is specified in 3GPP TS 03.03 section 4.3.2.
Change-Id: Id24ad64e6c6de080ab43faa272daf844fbba6954
Related: SYS#5315, OS#4940
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
In change [1] together with the actual implementation I introduced
a serious bug to bts_sched_fn(): if a timeslot is configured to use
frequency hopping, both 'pinst' and 'l1h' pointers are *overwriten*
in the inner loop, so the Downlink burst is re-directed to the
approproate PHY instance. However, if a subsequent timeslot is not
hopping, the Downlink burst would be re-directed to the wrong PHY
instance because both pointers were overwriten during a previous
iteration.
Let's move the 'struct phy_instance' pointer to the inner loop, so
it's properly re-initialized for each timeslot iteration.
Change-Id: I9afbbef8dc5d885763356470c27d4392dce8e815
Fixes: [1] I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
trx_phy_instance() does assert() that the given TRX pointer is
not NULL. In bts_sched_fn() it can never be NULL, so drop it.
Change-Id: I896ff5117588f2229cc54619ce62fd027a9ef25f
lower layer specific APIs require first to enable the TRX object
(GsmL1_PrimId_MphInitReq, which requires ARFCN received during Set
Radio Carrier Attributes) before enabling the per-TS structure.
Hence, OPSTART must happen in RCARRIER MO before OPSTART can be sent to
the Radio Channel MOs, otherwise the initialization of the TS objet will
fail and OPSTART for the RadioChannel MO will send back a NACK.
In order to avoid this, we need to keep the RadioChannel MO announced as
"Disabled Dependency" until RCARRIER is OPSTARTed.
Related: OS#5157
Change-Id: I8c6e5ff98c32a3cd5006f5e5ed6875bcabb1d85f
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
gsm_bts_trx_alloc() already does initialize some fields of the
allocated 'struct gsm_bts_trx' instance, and having an additional
function for initializing the other fields makes no sense.
Note that I intentionally didn't merge a call to bts_model_trx_init()
into gsm_bts_trx_alloc(), because this would break some assumptions
regarding the order of initialization and cause regressions.
This also allows us to not call bts_model_trx_init() from tests.
Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
For a long time, we see this annoying -Wstringop-truncation warning:
In function ‘parse_rsp’,
inlined from ‘trx_ctrl_read_cb’ at trx_if.c:647:6:
trx_if.c:416:2: warning: ‘strncat’ output may be truncated copying
between 0 and 45 bytes from a string of length 1495
416 | strncat(rsp->cmd, buf_in + 4, p - buf_in - 4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real need to use strncat() in parse_rsp(), because we
do not concatenate any strings but simply copy TRXC response parts
from the input buffer to the corresponding 'name' and 'parameters'
buffers. Let's use memcpy() instead. This also fixes the warning.
Change-Id: Ia10adf7d76abe9a423b07e828852fbfb53b95125
We need curly braces becausee1inp_line_get2() is basically a macro
that calls OSMO_ASSERT(), which in its turn contains an 'if' stmt.
Change-Id: I41a5fd13a7fa40e16bcf1a8099624b654274cee3
If the PHY is not powered on and we are not supposed to send any
bursts to it, then trx_if_send_burst() should just return early.
Change-Id: I578bd5a731ad88ebff283c75bb7eb268d9e7e787
Related: SYS#4895, OS#4941, OS#4006
If somehow the TRXC logic negotiates a non-supported TRXD PDU version,
then it's a serious bug in the code. Let's add an assert() for that.
Change-Id: I301377bcebd5e2bbcfc18b3637253ef261bb5b2e
Starting from TRXDv2, several PDUs may be batched together and sent in
all together a single datagram. This requires us to increase the buffer
size that we use for sending and receiving TRXD messages. Let's use
65536 matching the default MTU value for 'lo' interface on Linux.
Given that 65536 is quite a big number, let's allocate a shared Rx/Tx
buffer statically to avoid [potential] stack overflow.
Change-Id: I729451c8ecdc7ff2631beb423f15523db16b3ee3
Related: SYS#4895, OS#4941, OS#4006
This is a preparatory change for the upcoming TRXDv2 support:
* move common TRXDv0/v1 header parser into a separate function;
* move burst handling into a single, version independent function;
** determine modulation and burst length in trx_data_parse_pdu_v0();
Change-Id: I7aedd85a8d4f6d6191cd3b75272a688208fb2879
Related: SYS#4895, OS#4941, OS#4006
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
The current usage is to make osmo-bts-omldummy indicate BTS_FEAT_VAMOS
on OML, so that we can test osmo-bsc's behavior when VAMOS is enabled.
Related: SYS#4895
Depends: I699cd27512887d64d824be680303e70fff3677c1 (libosmocore)
Change-Id: Ib50990109f07884ef999ba5a4566f5d1d457b0ae
All these functions need the PHY instance pointer for logging,
they don't really need a pointer to 'struct trx_l1h'.
Change-Id: I626b4392a8bc57a3fe5e8c931aa1ce9dd505676c
Related: SYS#4895, OS#4941, OS#4006
The 'CHDR' stands for 'Common Header', but this does not apply to
TRXDv2 because TDMA frame number may not be present in the batched
PDUs. Let's avoid potential confusion by removing it.
Change-Id: I80495df474c432f4c0a4cfa6f917821d7b35859a
We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
This big comment is out of sync with what we have in the manuals,
so let's better remove it to avoid maintaining docs in several places.
Change-Id: Ibfcefcbb5f30fe9b6c691578a93e6fedd5644b30
Related: SYS#4895, OS#4941, OS#4006
TRXDv2 brings significant changes to the whole PDU structure, not
just the header. Let's highlight this in the code / strings.
Change-Id: Id0274bd1ae5c419548596ed1852e6a28ec62b713
Related: SYS#4895, OS#4941, OS#4006
New channel mode values have recently been added with change [1]
to 'enum gsm48_chan_mode'. The lack of default branch in
lchan2lch_par() caused build failures on Jenkins:
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V2_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V3_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V5_VAMOS’
not handled in switch [-Werror=switch]
This function is duplicated in osmo-bts-{lc15,oc2g,octphy,sysmo},
so we unfortunately need to apply the same fix to all copy-pasted files.
Change-Id: I557ff8cac6564d22485c101fba9212f5f0e95bb7
Related: [1] Ie0ea592da5610ae70290106d004e549cf3212a89
In change [1] I added the missing 'default' branch to the 'switch'
statement in lchan_tchmode_from_cmode(). This caused massive
regressions in ttcn3-bts-test, because osmo-bts started to NACK
some RSL CHANnel ACTIVation messages.
What caused a lot of regressions in ttcn3-bts-test is actually the
missing branch for RSL_CMOD_SPD_SIGN in the 'switch' statement.
It was not a problem before [1], because the 'default' branch was
not there. I was about to add the missing 'cause' when I realized
that this function needs to be reworked first...
First of all, lchan_tchmode_from_cmode() does a bit more than just
deriving RR (TS 44.018) channel mode from RSL (TS 48.058) channel
mode. It additionally stores the 'Speech or data indicator' to
the logical channel state, and also changes some global DTXd related
flags in 'struct gsm_bts'. Let's use a more precise name.
lchan_tchmode_from_cmode() -> rsl_handle_chan_mod_ie()
Together with renaming, it becomes logical to have the IE presence
check in rsl_handle_chan_mod_ie(), so that we can reduce code
duplication in the calling functions a bit.
Finally, the main problem is that coding and interpretation of the
6-th octet 'Speech coding algor./data rate + transp ind' depends on
the 4-th octet of the Channel Mode IE. We cannot handle all values
in one 'switch' statement without proper discrimination:
a) If octet 4 indicates Speech, then octet 6 shall be interpreted
as the GSM speech coding algorithm (FR, HR, AMR, etc.).
b) If octet 4 indicates Signalling, then octet 6 shall be set
to '00'O, because this is the only value defined in version
16.0.0 of 3GPP TS 48.058. All other values are reserved.
c) If octet 4 indicates Data, then octet 6 shall be interpreted
as CSD data rate further discriminated by service transparency.
Therefore, we need take both values into account. This can be
achieved by mixing them together using the bitwise operators,
just like we do in L1SAP code.
Change-Id: Iba967f5bd0cc8ad6cd3ccd40cca38b15ffe96b2c
Related: [1] I67a70132999be6580a29e6b814763309a6df4ae9
Related: SYS#4895, OS#4941
In [1] I introduced a regression, so osmo-bts started to complain:
This PHY does not support lchan TSC 3 != BSIC-TSC 7
on channel activation, despite the TSC in RSL_IE_CHAN_IDENT was 7.
The problem is that this statement:
cd = (const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT) + 1;
is basically equivalent to:
cd = ((const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT)) + 1;
so we actually shift the pointer by sizeof(struct gsm48_chan_desc)
and skip 3 octets instead of just one (IEI octet). Fix this.
Change-Id: Ic3a81396b60577e03c541d32839d07dc6d45c838
Fixes: [1] Id100f4c56fd5c1adad5d925d97240bed82981b9b
Fixes: OS#5121
* Calling l1if_provision_transceiver_trx() yelds nothing.
* It does not apply immediately, full restart required.
Change-Id: I93c9e19d0543f19528cec842b8be332b4d93214e
As the prefix in 'GSM48_IE_CHANDESC_2' implies, this IE belongs
to 3GPP TS 04.08 (or TS 44.018), so it can be used in the Radio
Resource assignment messages sent to the MS. While in this
function we're dealing with 3GPP TS 48.058, and thus the IEI
may be (and actually is) different for the RSL messages.
Also, according to 3GPP TS 48.058, section 9.3.5, the Channel
Description IE is included together with its element identifier,
so we need to skip one byte when doing the pointer casting.
Change-Id: Id100f4c56fd5c1adad5d925d97240bed82981b9b
Related: SYS#4895, OS#4941
Instead of blindly assuming what the PHY does support, and what
it does not, let's check the related feature vector.
Change-Id: I699cdddbfab111855998853548d9cfe956f7c60c
Related: SYS#4895, OS#4941
If for whatever reason it fails to initialize the TRXD or TRXC
interface, trx_phy_inst_open() would return an error. This
would cause bts_model_phy_link_open() to call trx_if_close()
on each of the PHY links, including those that were never
opened. This leads to a segfault in trx_if_close().
Make sure that in trx_if_init() we properly init 'struct trx_l1h',
so it's safe to call trx_if_close() at any time and in any state.
Change-Id: I1f128813528f505fede04799e84456f6271058d0
The measurement results / TCH indications that are handed when decoding
the TCH/H are off by two bursts. Since a measurement result / TCH block
is expected every two bursts anyway the problem can only be noticed when
a FACCH transmission is going on and the frame numbers of the BFI TCH
blocks appear to be missaligned towards the FACCH block.
The reason is that the incoming bursts are shifted into a 6 burst wide
buffer. The decoding functions always look at the beginning of that
buffer while the bursts are shifted into the buffer from the end. A
facch will always fit exactly in that buffer but TCH/H blocks are only
4 bursts wide and thereofre they need two additional bursts until they
reach the coverage of the decoding function. Lets fix this by putting
the correct frame number (from two bursts before) into the remap
functions in order to get the correct beginning of the block.
Since the FACCH transmission uses six blocks it takes out two TCH
blocks. This means that if we count the FACCH block we end up with a gap
of one TCH voice block. Lets generate a dummy measurement to compensate
the gap. This will also match the behavior of the osmo-bts-sysmo phy.
Change-Id: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
Related: OS#4799
By reordering the instruction, we scheduler the timerfd prior to
processing the FN on the upper layers. This means the first timerfd
expiration even will happen more inline with the expected time, that is,
CLOCK IND time + GSM_TDMA_FN_DURATION_nS.
Let T(trx_sched_fn) be the time spent executing function trx_sched_fn().
With previous order, the timerfd would have been scheduled later, which
in the end would mean expiration would happen at time CLOCK_IND +
GSM_TDMA_FN_DURATION_nS + T(trx_sched_fn), hence ending up with an extra
skew of T(trx_sched_fn) added by ourselves.
This extra skew added may be important specially at startup time (when
this code path is used), since usually the load in the system is high
and skew is usually already higher, which means helping crossing
unacceptable thresholds which may end up in osmo-bts-trx stopping with
"No clock from osmo-trx" reason.
Change-Id: Ie2ba35cd87f0bd4078ac3b4b5ec2eacad36c4258
These fields are always aready set by the only caller of the function
trx_setup_clock(), so there's no use in re-setting them.
Change-Id: Id8a7141984e07eb11abae08e0c63ae7ebc333511
It can happen that the first burst we receive after enabling the PDCH
channel (when PCU connects to the BTS) is bid!=0. As a result,
chan_state->ul_first_fn is never set and defautl value 0 in there is
passed to the upper layers. As a result, when the 2nd block is
transmitted, this time with correct FN, the PCU will see a huge jump in
FNs. Since in PDCH the bursts are always consecutive, let's simply use
bi->fn - 3 as a first_fn and be done with the issue.
Related: OS#5020
Change-Id: Ie982caeb29f3ffd880b44e88a89b85ea3e6e6947
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I343c7a721dab72411edbca816c8864926bc329fb
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I0b04b013b7bad5ff53d6a969ff0128b37f7f62d5
At the moment osmo-bts is not looging much ACCH repetition related
information. This makes testing ACCH repetition difficult. Lets add some
debug output that informs the user when ACCH repetition is turned on or
off. Lets also add an ACCH repetition status display to the show lchan
VTY command.
Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e
Related: SYS#5114
The MS sets the SRR bit in the L1 SACCH header to request DL-SACCH
repetition from the BTS. At the moment we access the l1_info stored in
tle lchan struct each time we want to check the status of the SRR bit.
However, it is more convinient to do this once at reception and store
the status of the status of the flag in a separate struct member.
Change-Id: Ieddd45d7890343d64db14b9c726f6fa2f25714f6
Related: SYS#5114
2021-03-01 19:47:56 +00:00
300 changed files with 28591 additions and 8362 deletions