The idea is to have a base static value which is set like before "timer
t3113 [seconds]", but now have a part of this timeout calculated
dynamically based on BTS channel configuration and channel load.
This patch only implements initial support to calculate based on channel
configuration, but doesn't include code to calculate based on channel
load. To implement the later part, we probably need to keep track of BTS
paging queues per paging group, which we don't do nowadays.
Dynamic calculation is enabled by default, and default static base value
is decreased accordingly. This way, in a typical setup were the default
10 seconds were used, now the calculated final value is 11 seconds.
That's intended because it was observed experimentally in osmo-gsm-tester with
a similar channel setup that sometimes paging response can arrive slightly
later than 10 seconds.
Related: OS#3680
Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
When we enter WAIT_RLL_RTP_RELEASED
(lchan_fsm_wait_rll_rtp_released_onenter), we call lchan_do_release()
which in turn dispatches LCHAN_RTP_EV_RELEASE to lchan_rtp_fsm.c, which
will dispatch back an LCHAN_EV_RTP_RELEASED event, which will be handled
by lchan_fsm_wait_rll_rtp_released(), which will change state to
WAIT_BEFORE_RF_RELEASE. When going back the stack (return), we are still
in lchan_fsm_wait_rll_rtp_released_onenter() which again triggers a
change state to WAIT_BEFORE_RF_RELEASE because it checks same conditions
than first one.
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1388 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: lchan detaches from conn SUBSCR_CONN(conn3)[0x612000002da0]
20181128203727051 DMSC osmo-bsc/lchan_fsm.c:1391 SUBSCR_CONN(conn3)[0x612000002da0]{CLEARING}: lchan lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] detaches from conn
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1359 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: state_chg to WAIT_RLL_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:959 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) SAPI[0] = 1
20181128203727052 DRR osmo-bsc/gsm_04_08_rr.c:254 Sending Channel Release: Chan: Number: 0 Type: 2
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:945 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Received Event LCHAN_RTP_EV_RELEASE
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Freeing instance
20181128203727052 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Deallocated
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: Received Event LCHAN_EV_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:856 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) Still active SAPIs: 0
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:1011 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: state_chg to WAIT_BEFORE_RF_RELEASE
20181128203727052 DRSL osmo-bsc/abis_rsl.c:633 (bts=0,trx=0,ts=6,ss=0) DEACTivate SACCH CMD
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:986 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_BEFORE_RF_RELEASE}: transition to state WAIT_BEFORE_RF_RELEASE not permitted!
Change-Id: I5d95bbd8244cc8e9c1cfb6fe0f76148332386a3d
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
When lchan_rtp_fsm instance is allcoated with
osmo_fsm_inst_alloc_child(..., LCHAN_EV_RTP_RELEASED) we already let fsm
code to take care of sending that event ito the parent when the fsm is
terminated (but only if freeing cause is not OSMO_FSM_TERM_PARENT).
The lchan_rtp_fsm cleanup() callback, which is called immediatelly before
sending to the parent the event defined during osmo_gsm_install_alloc_child(),
currently also sends that same event, which ends up in a duplicated
event being sent as shown in log files below.
Let's only send the event in cleanup() if we are in the
cause=OSMO_FSM_TERM_PARENT scenario, to make sure parent always receives the
event, but only once.
20181128193707326 DAS osmo-bsc/assignment_fsm.c:127 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=6,ss=0) Assignment failed
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Terminating (cause = OSMO_FSM_TERM_ERROR)
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Removing from parent SUBSCR_CONN(conn4)[0x612000002920]
20181128193707326 DCHAN osmo-bsc/lchan_fsm.c:1333 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Received Event LCHAN_RTP_EV_ROLLBACK
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST)
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:441 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: notify=NULL
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:482 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: Scheduling
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:742 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance
20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated
20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted!
20181128193707330 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Freeing instance
20181128193707330 DAS fsm.c:381 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Deallocated
Change-Id: I3e95a21e5a5ec6c35b1ab20b7a642fd7eb81e556
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
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: Ief6ce94013612a968183e82abef421f116ed37c3
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I38bd2bffa24c5b970aa4a42dcfc8d8766bb96046
Every DTAP message coming from the MSC has a header (see struct
dtap_header) that contains message type, length, and link ID.
The link ID indicates SAPI and channel type of a given message.
In dtap_rcvmsg() we allocate a new message buffer and copy the
received message into it. The old message buffer is freed by
the caller then.
The link ID value parsed from DTAP header is usually being stored
in the control buffer of a message buffer (i.e. msgb->cb). Due to
a mistake, it was stored in the old (to be freed) message, while
the new (to be forwarded) message always had link_id = 0x00!
This change resolves the problem with sending SMS during a voice
call, when MT signalling goes through FACCH, while MO signalling
goes through SACCH.
Change-Id: I7675e1ce4436fad836778261ac9d446fa8f81483
Related: OS#3716
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged
before fixeria's code review could be incorporated.
Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
If BTS is configured to have only TCH/F_PDCH and TCH/H and a call is
resolved to require TCH/F, don't return the TCH/H which have no use, but
instead let it allocate the TCH/F_PDCH.
20181128185013783 DRLL <0000> lchan_select.c:159 (bts=0) lchan_select_by_type(TCH_F)
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=3,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=4,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=5,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=6,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=7,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:86 looking for lchan TCH/H: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) ss=0 is available
20181128185013784 DCHAN <0010> lchan_select.c:253 lchan(0-0-2-TCH_H-0)[0x6120000066a0]{UNUSED}: (type=TCH_H) Selected
Change-Id: I9a73beb0432fab16d5430e5b40d470694e09b189
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in local the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I92c0f771d4ffc2b0401d26e25cb0b3817e6f95ea
Includes from other projects don't work anymore when moving project
specific manuals into other repositories.
Related: OS#3385
Change-Id: I96933dd4dd6cac159847647f1c642215051a9aad
Re-generate bsc_vty_reference.xml from osmo-bsc, including updates to:
- handover and neighbor config
- SCCP timers
- logging
Change-Id: Ia9ba8d5eba531b1156de57573ab42517e0c1ca15
Add chapter "Handover", explaining:
- intra- and
- inter-BSC handover,
- HO algorithm 1 and
- algorithm 2
- new neighbor configuration
Adjust copyright, add revision and add me as author.
Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Update bsc_vty_additions.xml to match the new node ID scheme.
Change-Id: I0d856563eee88527fda4c6940aa6cea779175aaa
The initial goal was to make sure we don't have overall FORCE rules causing
unnecessary rebuilds -- annoying while writing documentation. As I looked
through possible dependencies, I finally understood what's going on here.
Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In
each, describe in a top comment how to use it, and also unify how they are
used:
- Rename Makefile.inc to Makefile.docbook.inc and refactor
- Add Makefile.vty-reference.inc
- Add Makefile.common.inc
Make sure that we accurately pick up all dependencies.
Drop use of the macro called 'command', that silenced the actual command lines
invoked and replaced them with short strings: it obscures what is actually
going on and makes the Makefiles hard to read and understand.
Each manual's makefile is greatly reduced to few definitions and a Makefile
include, e.g. one for asciidoc, one for VTY reference.
Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link
from OsmoNITB. It applies only to OsmoBSC and OsmoNITB.
Add a script that combines a VTY reference file with *all* additions files
found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc.
Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
All parts referencing GFDL can be easily disabled by removing the
'gfdl-enabled' attribute from the document.
Change-Id: I2489726ad2e90301bceadfada926e31ae0f85986
According to RFC3435, an RTP bridge forrwarding packets, transcoding
or otherwise, is a single endpoint with two connections. Let's treat
it as such. We introduce the "rtpbridge/" prefix to identify such
special RTP endpoints.
Change-Id: Id1f079307225faf05d298dcb12aa1c421bfa680a
Oliver Smith
Pau Espin
Vadim Yanitskiy
Harald Welte