So far the number of usable lchans is determined on-the-fly by the
physical channel config. With VAMOS, this becomes more complex, namely
determining whether the BTS is vamos capable.
Instead of calling a function to determine the number of lchans for
every use, rather place the number of valid lchans in int members of the
timeslot struct, and initialize those during timeslot setup.
Actual use of these new fields will follow in a subsequent patch, which
introduces the ts_for_n_lchans() macro to replace current lchan
iteration macros.
Related: SYS#5315 OS#4940
Change-Id: I08027d79db71a23e874b729c4e6173b0f269ee4f
Before this patch FSM instances of configured but not connected BTS's
look like this:
FSM Instance Name: 'timeslot[0x612000004a20]', ID: '(null)'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
Now they look like this:
FSM Instance Name: 'timeslot(0-0-7-NONE)[0x612000004a20]', ID: '0-0-7-NONE'
Log-Level: 'DEBUG', State: 'NOT_INITIALIZED'
which makes it possible to attribute them to where they belong.
Otherwise, they look like lingering or leaking unattributed FSM
instances.
Change-Id: Idc74ea142b96323b48826f8a52e13e45d535512a
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
It should be fine if we receive PDCH_ACT_ACK late. We should just go
into the PDCH state as normal.
Change-Id: If816b681e0b2e76fb7122cf211e15eeee92451ee
lchan sends TS_EV_LCHAN_UNUSED to its parent (ts) during release time. It
was experimentally found that it can happen that an lchan can be terminated
while waiting for a PDCH DEACT (N)ACK response.
The fsm definition actually states that this event can be received in
state TS_ST_WAIT_PDCH_DEACT, but it was not handled before and as a result the
process aborted due to the default switch case.
Change-Id: If61493e7d5449bf2c2de9fd34cdf2410625e92ac
Before this patch, TCH lchans waiting for dynamic TS to
switch PDCH->TCH wouldn't be counted.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I32008859cc23cd2afddd79daae21497d0945fed0
If TS is in state changing from PDCH->TCH, the TCH lchan provoking the
switch would be skipped and not terminated before this patch.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I9dc2a6e5b15376d049bd2ac5ddfa24340771b5c8
If ts_is_lchan_waiting_for_pchan() wasn't accounting for TCH lchans
waiting for TS to deactive PDCH in order to setup the TS as TCH.
Since now TCH lchan is catched by ts_is_lchan_waiting_for_pchan() when
TS state is TS_ST_WAIT_PDCH_DEACT, there's no need to check for that
case in caller ts_is_pchan_switching(), since it will never hit because
the callee returns true in that case now.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: Ib03e5a91438a5b74a04e69f81fab565842b02b66
Documentation of the function explicitly states that the out
target_pchan param returns the "PCHAN waited for". If we return false,
then no PCHAN is being waited for. The 2 callers of this function only
use this out param if function returns true, so let's simplify the code.
Change-Id: Ib8f9b7e1f584dee885d6823dc043682577572bd8
In general PDCH channels are not handled as lchans in BSC (lchan_fsm.c),
and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is
being used.
However, during Dynamic TS PDCH Deactivation being in progress (state
WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but
an lchan slot of that TS is actually already being used by a TCH lchan:
it's the one who initiated the deactivate in order to be able to use the TS.
While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK,
ts_fsm_error() was called in order to kill the TS and it was expected
that it would kill any lchan using it (or willing to start using it). In
order to do that, it calls ts_lchans_dispatch() which in turns iterates
over all lchans attached to the TS using ts_for_each_lchan().
However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH,
ts_for_each_lchan ends up calling
ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls
pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage
lchans in that mode as explained in first paragraph. This means in this
case ts_for_each_lchan() is actually an empty loop while still any of
the TCH channels may be in use, and won't be advertised about the TS
entering in a broken state.
As a result, the lchan won't be released for a while, only after T23001
expires.
Related: OS#3708
Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
It will be used further in follow-up patches. It also provides a place
to document its (intricate) logic around it and its possible uses.
Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
In case a given channel combination contains a CBCH, it replaces sub-slot 2
with a CBCH, i.e. we must not attempt to allocate the same for SDCCH.
On timeslot initialization, immediately place such an lchan FSM into new state
LCHAN_ST_CBCH, so that it never appears unused and never is picked during
lchan_select(). Also set lchan->type = GSM_LCHAN_CBCH.
Verified by configuring CBCH timeslots and watching 'show lchan summary'.
Immediately after RSL and OML are up, these pchan types show lchan 2 in state
CBCH:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
With a 'phys_chan_config ccch+sdcch4+cbch' and three phones simultaneously
requesting USSD, I see:
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 0, Type SDCCH, State ESTABLISHED - L1 MS Power: 14 dBm RXL-FULL-dl: -53 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 1, Type SDCCH, State ESTABLISHED - L1 MS Power: 30 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 0 CCCH+SDCCH4+CBCH, Lchan 3, Type SDCCH, State ESTABLISHED - L1 MS Power: 16 dBm RXL-FULL-dl: -47 dBm RXL-FULL-ul: -47 dBm
With 'phys_chan_config SDCCH8+CBCH' and three phones simultaneously attaching,
I see:
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 0, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 1, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 2, Type CBCH, State CBCH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
BTS 0, TRX 0, Timeslot 1 SDCCH8+CBCH, Lchan 3, Type SDCCH, State WAIT_RLL_RTP_ESTABLISH - L1 MS Power: 0 dBm RXL-FULL-dl: -110 dBm RXL-FULL-ul: -110 dBm
i.e. in all cases the CBCH lchan remains occupied and is not allocated as
SDCCH.
Detaching and re-attaching the BTS reliably brings back the CBCH state. Also
verified that changing the osmo-bsc config from telnet vty and dropping oml
followed by the BTS re-attaching brings back the CBCH state.
Change-Id: I2bafc5f696e818e38f8907ad0c8f38494df0623d
If PDCH ACT sending fails and we go back to UNUSED, the UNUSED onenter goes
right back to PDCH ACT and we loop. Avoid by going straight to broken state.
Actually, if we can't send messages, the timeslot is obviously broken, so also
enter the broken state if PDCH deactivation fails to be sent out.
Change-Id: Iebaffd0547a9651c5ba435b54dedab99c2cfdd31
Before this patch, the timeslot FSM receives OML and RSL ready events.
Afterwards, it relies on examining the RSL and OML status to match the received
events. This doesn't work for the ip.access nanobts, which fails to change the
CHANNEL OM's operational status even though it has sent an Opstart ACK. We
receive OML CHANNEL Opstart ACK, but the mo's state left at OP_STATE=Disabled.
We apparently cannot rely on the gsm_abis_mo state as assumed before this
patch, since changing the state depends on each BTS vendor's OML
implementation.
Also, implementation wise, it is better to not include assumptions on RSL and
OML implementations in the timeslot FSM. Simply receive the OML and RSL ready
events and remember that they arrived in dedicated flags.
Remove the no longer needed oml_is_ts_ready() callback from struct
gsm_bts_model added in:
commit 91aa68f762
"dyn TS: init only when both RSL and the Channel OM are established"
I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
This keeps osmo-bts operational while fixing ip.access nanobts, where the
CHANNEL OM's state prevented the timeslot FSM from entering operation.
Change-Id: I4843d03b3237cdcca0ad2041ef6895ff253d8419
Add FSMs:
- timeslot_fsm: handle dynamic timeslots and OML+RSL availability.
- lchan_fsm: handle an individual lchan activation, RTP stream and release,
signal the appropriate calling FSMs on success, failure, release.
- mgw_endpoint_fsm: handle one entire endpoint with several CI.
- assignment_fsm: BSSMAP Assignment Request.
- handover_fsm: all of intra, inter-MO and inter-MT handover.
Above FSMs absorb large parts of the gscon FSM. The gscon FSM was surpassing
the maximum amount events (32), and it is more logical to treat assignment,
handover and MGW procedures in separate FSMs.
- Add logging macros for each FSM type:
- LOG_TS()
- LOG_LCHAN()
- LOG_MGWEP(), LOG_CI()
- LOG_ASSIGNMENT()
- LOG_HO()
These log with the osmo_fsm_inst where present.
New style decision: logging without a final newline char is awkward,
especially for gsmtap logging and when other logs interleave LOGPC() calls;
we have various cases where the final \n goes missing, and also this invokes
the log category checking N times instead of once.
So I decided to make these macros *always* append a newline, but only if
there is no final newline yet. I hope that the compiler optimizes the
strlen() of the constant format strings away. Thus I can log with or without
typing "\n" and always get an \n termination anyway.
General:
- replace osmo_timers, state enums and program-wide osmo_signal_dispatch()
with dedicated FSM timeouts, states and events.
- introduce a common way to handle Tnnn timers: gsm_timers.h/.c: struct T_def.
These can be used (with some macro magic) to define a state's timeout once,
and not make mistakes for each osmo_fsm_inst_state_chg().
Details:
bsc_subscr_conn_fsm.c:
- move most states of this FSM to lchan_fsm, assignment_fsm, handover_fsm and
mgw_endpoint_fsm.
- There is exactly one state for an ongoing Assignment, with all details
handled in conn->assignment.fi. The state relies on the assignment_fsm's
timeout.
- There is one state for an ongoing Handover; except for an incoming Handover
from a remote BSS, the gscon remains in ST_INIT until the new lchan and conn
are both established.
- move bssmap_add_lcls_status() to osmo_bsc_lcls.c
abis_rsl.c:
- move all dynamic timeslot logic away into timeslot_fsm. Only keep plain send/receive functions in
abis_rsl.c
- reduce some rsl functions to merely send a message, rename to "_tx_".
- rsl_ipacc_mdcx(): add '_tx_' in the name; move parts that change the lchan state out into the
lchan_fsm, the lchan->abis_ip.* are now set there prior to invoking this function.
- move all timers and error/release handling away into various FSMs.
- tweak ipa_smod_s_for_lchan() and ipa_rtp_pt_for_lchan() to not require an
lchan passed, but just mode,type that they require. Rename to
ipacc_speech_mode*() and ipacc_payload_type().
- add rsl_forward_layer3_info, used for inter-BSC HO MO, to just send the RR
message received during BSSMAP Handover Command.
- move various logging to LOG_LCHAN() in order to log with the lchan FSM instance.
One drawback is that the lchan FSM is limited to one logging category, i.e. this moves some logging
from DRR to DRSL. It might actually make sense to combine those categories.
- lose LOGP...LOGPC logging cascades: they are bad for gsmtap logging and for performance.
- handle_classmark_chg(): change logging, move cm2 len check out of the cm3 condition (I hope that's
correct).
- gsm48_send_ho_cmd(): split off gsm48_make_ho_cmd() which doesn't send right away, so that during
inter-bsc HO we can make an RR Handover Command to send via the MSC to the remote BSS.
assignment_fsm.c:
- the Chan Mode Modify in case of re-using the same lchan is not implemented
yet, because this was also missing in the previous implementation (OS#3357).
osmo_bsc_api.c:
- simplify bsc_mr_config() and move to lchan_fsm.c, the only caller; rename to
lchan_mr_config(). (bsc_mr_config() used to copy the values to mr_bts_lv
twice, once by member assignment and then again with a memcpy.)
- During handover, we used to copy the MR config from the old lchan. Since we
may handover between FR and HR, rather set the MR Config anew every time, so
that FR rates are always available on FR lchans, and never on HR lchans.
Depends: I03ee7ce840ecfa0b6a33358e7385528aabd4873f (libosmocore),
I1f2918418c38918c5ac70acaa51a47adfca12b5e (libosmocore)
Change-Id: I82e3f918295daa83274a4cf803f046979f284366
Neels Hofmeyr
Pau Espin