The function reduce_rach_dos() only removes the tossed channel requests
from the list, but does not free them.
Change-Id: I0a62fc897c07e118dd637b156b6f2822c44db731
Related: OS#4549
At the moment expired channel requests are dropped silently, however, it
might help to know when this happens - not only for debugging.
Change-Id: Ib49df551a4cd7d5652e85c8ce29ef132385d4ae4
Related: OS#4549
when an emergency call arrives while all TCH are busy, the BSC should
pick an arbitrary (preferably the longest lasting) call / lchan and
release it in favor of the incoming emergancy call.
The release of the existing call is a process that can not be done
synchronously while the ChanRQD is handled sonce multiple messages are
exchanged between BTS and MSC and multiple FSMs need to do their work.
To be able to release one lchan while handling a ChanRQD a queue is
implemented in which the incomming channel requests are collected. If
an emergency call is established while all channels are busy, an
arbitrary lchan is picked and freed. When freeing the lchan is done,
the queue is checked again and the emergency call is put on the free
lchan (TCH/H or TCH/F).
Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36
Related: OS#4549
osmo-nitb supports the modification of an lchan if the lchan is
compatible but in the wrong mode. This feature was dropped in the
transition to AoIP/bsc-split. However, osmo-bsc still has code to
generate and parse the messeages, but the FSMs do not support a mode
modify yetm
Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in
order to support mode modify again
Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb
Related: OS#4549
Currently osmo-bsc encodes the IAR Rest Octets as follows:
IAR Rest Octets
0... .... = Extended RA: Not Present
.0.. .... = Extended RA: Not Present
..1. .... = Extended RA: Present
...0 1011 = Extended_RA: 11
0... .... = Extended RA: Not Present
.L.. .... = Additions in Rel-13: Not Present
Padding Bits: default padding
This is not really critical, but still may look confusing as this
is only relevant for the PS domain (11-bit RA), while osmo-bsc is
responding to a CHANNEL REQUEST in the CS domain.
Change-Id: I30a43efc70345a4bb0571127c239a24422b7fd2c
If a CHAN RQD indicates an emergency call on a BTS that does not allow
emergency calls, then respond with an IMMEDIAGE ASSIGNMENT REJECT
message to deny the emergency call early.
Related: OS#4548
Change-Id: I148c540269bffd703f38233a1e689e863c175e97
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
According to 3GPP TS 48.058 (version 15.0.0), section 9.3.5, the
3GPP TS 24.008 "Mobile Allocation" shall for compatibility reasons
be included but empty, i.e. the length shall be zero. Therefore,
no matter if frequency hopping is in use or not, send it empty.
Change-Id: Ie224a45f10522332eac653fa371564f022108c3f
Related: OS#4545, OS#4546
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends
us an RSL DELETE INDICATION. So far, osmo-bsc logs this as
<0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14
which is not very helpful. Instead, make the log message more
descriptive and add a rate counter for monitoring.
Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4
Closes: OS#3190
Not sure why this specific message is ERROR while similar ones around
are DEBUG. So let's fix this disparity by demoting this message level.
Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
The "CHAN RQD: reason" message is purely informational and is a part
of normal operation. Nothing to NOTICE there. Let's demote this to
DEBUG.
Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
Lots of times, the MS power class is unknown until after the first
channel has been activated, at which point the MS power class is
received in messages such as LU update or CM Service Requet.
Since the MS Power level is sent upon CHAN ACT, the only way to
communicate the change of maximum MS Power (based on MS power class)
after CHAN ACT is to send a MS Power Control msg. Let's do that.
Related: OS#4244
Change-Id: I3d6b75578e5cb9b2ad474a0ad01362d846ebe135
Since MS Power Param IE content is operator dependant, it's currently
not known which kind of content non-osmocom BTS support/allow, so let's
avod possibily breaking those BTS until each BTS has been checked
separately.
Related: OS#1622
Change-Id: If44121222042bdac06c2a5e70f7b35a88b00b27c
Further accesses will be addter in forthcoming commit, so let's first
store the pointers in variables to clean up the code.
Change-Id: Ie5ea0f44dfb5731cab7e8e5a3dd3d791ee703df7
TS 48.058 sec 8.4.1 CHANNEL ACTIVATION and state:
"""
The BS and MS Power Parameters elements are included to indicate that BS
and/or MS power control is to be performed by BTS. The maximum power to
be used is indicated in the BS and MS Power elements respectively.
"""
Since we always want the BTS to do autonomous MS power control, let's
add it.
Related: OS#1622
Change-Id: Icaaa61b363b093f00b6653c3df64d3e66583b9f8
In addition to transmission of the ETWS Primary Notification via all
dedicated channels, we also need to send it to the BTS for transmission
via PCH (P1 Rest Octets) and for forwarding to PCU for PACCH
transmission.
Change-Id: I7e45b0373458a4348b12b92dd92861062532548b
This adds code to handle CBSP (Cell Broadcast Service Protocol)
from the CBC (Cell Broadcast Centre), as well as BSC-internal data
structures for scheduling the various SMSCB on the CBCH of each BTS.
There are currently one known shortcoming in the code: We don't yet
verify if keepalives are received within repetition period.
Change-Id: Ia0a0de862a104d0f447a5d6e56c7c83981b825c7
It's quite ugly to have manual "bts=%d" printf-statements all over
the BSC code. Let's change this to use shared logging helper functions
all over the place, whenever we need to log something related to one
BTS or one TRX.
This can also help us as the first step to later add alternative logging
of BTS identities, e.g. by printing the Cell Global Identifier or
LAC+CI, or even a human-readable/vty-defined 'name' of the BTS, rather
than its numeric bts number. With this change in place, we can
introduce such changes at a single location in the code.
Change-Id: I4a7814d164384eecfb6913c31802cf2faead6e6c
Now that OsmoBTS is generating CBCH LOAD IND messages, let's avoid
spamming the BSC log with notices about receiving this unimplemented
message.
Change-Id: Ida5045ec7a18c1062a3b80a381db52d5c98e9966
Now that OsmoBTS understands about extended CBCH, let's at least
update the BSC side function to allow for other code to generate
such messages.
Change-Id: I77a16b75ce311d63fb022475c8ff25fbbcee7f55
Move the T_defs API to libosmocore as osmo_tdefs: remove the local T_defs API
and use libosmocore's osmo_tdef* API instead.
The root reason is moving the mgw_endpoint_fsm to libosmo-mgcp-client to be
able to use it in osmo-msc for inter-MSC handover.
When adding osmo_tdef, the new concept of timer groups was added to the API. It
would make sense to apply group names here as well, but do not modify the VTY
configuration for timers. The future might bring separate groups (or not).
Depends: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 (libosmocore)
Change-Id: I66674a5d8403d820038762888c846bae10ceac58
On rsl_rx_chan_rqd(), so far osmo-bsc tried to preferably assign the lchan type
that was asked for in the RACH. Firstly, this contained a bug, and secondly,
it does not make sense to heed that preference, since we do late assignment.
Ignore the preference for the MS' TCH kind.
We do late assignment to avoid codec mismatches. In the "old days", we would
heed the MS' TCH channel kind, even if the MSC or BSC didn't actually allow
or prefer that channel kind. Hence, in the presence of both TCH/F and TCH/H,
the MS could ask for TCH/F (which we would grant on the MO side) and the BSC
or MSC could prefer TCH/H (which we would apply on the MT side), and hence
fabricate a codec mismatch. Instead, since quite some time now, we *always*
assign an SDCCH first, and only later on do another Assignment to hand out
a proper voice lchan that heeds the MS capability bits as well as MSC's and
BSC's preferences.
By completely ignoring the channel kind the MS asked for in the RACH, we
also eliminate this bug in rsl_rx_chan_rqd():
- If the first "lchan_select_by_type(GSM_LCHAN_SDDCH)" fails (all SDDCH in use),
we should try to fall back to any TCH instead, to serve as SDCCH.
- the first "if (!lchan && lctype != GSM_LCHAN_SDCCH)" was an attempt to prefer
a fallback to the lchan type the MS requested.
- the remaining two "if (!lchan && lctype == GSM_LCHAN_SDCCH)" were obviously
only applied if the MS asked for an SDCCH, and skipped if the type was TCH/*.
- hence, missing was: if the MS asked for a TCH, to also try the *other* TCH
kind that the MS did not ask for. (Example: all SDCCH in use, MS asks for
TCH/F, but BSC has only TCH/H lchans; we should assign TCH/H as SDCCH, instead
we said "no resources")
Change-Id: Ie3684cf071751f9528183d761c588102936e498c
Related: OS#3503
The function lchan_alloc() does not exist anymore, however there is
still a prototype definition in chan_alloc.h and a comment in
abis_rsl.c. Lets remove those.
Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX
generation into separate function with the ability to set destination
explicitly instead of just using the value from lchan which will be used
in follow-up patches.
Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8
Related: OS#3659
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
Separate the cause value passed to further functions from the log string.
The code tried to be nice by composing the RSL cause string and returning the
RSL cause at the same time, which falls on its face when the string composition
happens only within conditional logging.
Change-Id: Ibadd06102f162bca9182c39b77b0651568d3e6f8
Set msgb->l3h when composing the L3 message. Before this, the unset l3h
resulted in erratic size in the RSL L3 Info IE. This likely fixes inter-BSC
Handover on the outgoing side, to properly forward the RR Handover Command.
Change-Id: Ice37242c90c19adbf0795618fd16fe75f0809317
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
"utils" suggests thin helpers to aid using a proper API, while this .c file
actually *is* the proper RR API. Rename from "utils" to "rr".
Change-Id: I0ffff63d57f03cb324df8e40e41caea5b55a2c85
The payload constants for AMR, EFR, GSM-FR, and GSM-HR are already
defined in libosmo-netif, there is no need to re-define them locally.
- include rtp.h from libosmo-netif in abis_rsl.c
- remove duplicate payload type constants
Change-Id: Ib6a866b29d863d6875c67748dbe6b6468941ab29
Related: OS#2728