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
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
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
- 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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
Mychaela N. Falconia
Vadim Yanitskiy
Philipp Maier
Pau Espin
Harald Welte
Daniel Willmann