I noticed during testing that an lchan used as TCH/F in fact still had
its channel mode set to Signalling -- because on Assignment, the Speech
mode used to be placed in the *previous* lchan and the new lchan was
never updated after the Activ ACK. This is unbearable confusion which I
complained about numerous times, so far mostly for cosmetic reasons. But
implementing re-assignment properly actually requires this to be cleaned
up.
Keep all volatile chan mode settings in lchan->activate.* or
lchan->modify.*, and only update lchan->* members when an ACK has been
received for those settings. So a failed request keeps a sane state.
Make sure that those settings are in fact updated in the proper lchan,
upon an ACK, so that subsequent re-assignment or mode-modify know the
accurate lchan state.
Related are upcoming patches that sort out the AMR multirate
configuration in a similar fashion, see
Iebac2dc26412d877e5364f90d6f2ed7a7952351e
Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9
Ie57f9d0e3912632903d9740291225bfd1634ed47.
Related: SYS#5315 OS#4940 OS#3787 OS#3833
Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
So far, only the MSC asked for Assignment via Assignment Request, which
we answer with a BSSMAP Assignment Complete or Assignment Failure when
done.
When Assignment is triggered for any other reason (congestion
resolution, VAMOS, VTY), we will not send any such messages to the MSC.
Additional enum values will be added in subsequent commits:
Id56a890106b93fcee67ac9401b890e7b63bba421 ASSIGN_FOR_CONGESTION_RESOLUTION
If006f5caaf83b07675f57e5665cfa79328da55e6 ASSIGN_FOR_VTY
Related: SYS#5315 OS#4940
Change-Id: Ie0cddbdb00abcec78e153f4ae6d04ce75080a111
In practice, '+ true' may result in '+ 1', but that is not type safe. We
rely on the number of items added by summing up booleans, rather make it
explicitly 1.
Change-Id: I17a82f4f208203b748ba2d6ace0ddc06f87c1cef
"""
The old BSS shall inform the new BSS of the MS's last used E-UTRAN PLMN
in the "Last used E-UTRAN PLMN ID" information element included in the
"Old BSS to New BSS information" Information Element if this information
is present.
"""
Depends: libosmocore.git Change-Id I6280ce1abc283f1491bc6f391b2dd952df33a16b
Related: SYS#5337
Change-Id: I6cf54f9a16d598f98dc56b25f0fef56225a25a28
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""
Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""
Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.
This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.
Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.
Related: SYS#5337
Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
We cannot simply use the highest 'x' in A5/x codecs.
For A5/7 through A5/3, larger 'x' means better.
But: A5/1 is better than A5/2, so we need to prefer the former
over the latter.
Change-Id: I399fff8d07d1bfcbc6b385e90914ff6d9e00eb73
Closes: OS#4975
The function bssmap_handle_cipher_mode() suggests to check if an lchan
is actually present when it gets called, but it only checks for conn.
This might lead to a segfault later in the execution path.
Change-Id: I3103ec89cd6dce1a11ea8e9f8187373e4114e852
So far we would cancel ongoing Paging for a given MSC only after receiving a
RESET message from that BSC. However, the typical operation would be that
OsmoBSC *sends* a RESET and receives a RESET-ACK.
Instead, move the call to within osmo_bsc_sigtran_reset(). This is also called
when OsmoBSC considers the A-interface link to be lost, from the a_reset.c
code, after multiple SCCP connection failures.
Change-Id: Ia14b916be56563d18632c69a833084e71799a468
Data Link Connection Identifier (DLCI) is defined in 3GPP TS 48.006,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
CC.. .... - control channel identification:
00.. .... - indicates that the control channel is not further specified,
10.. .... - represents the FACCH or the SDCCH,
11.. .... - represents the SACCH,
other values are reserved.
RSL Link Identifier is defined in 3GPP TS 3GPP TS 48.058,
section 9.3.2, and coded as follows:
.... .SSS - SAPI value used on the radio link;
...P P... - priority for SAPI0 messages;
CC.. .... - control channel identification:
00.. .... - main signalling channel (FACCH or SDCCH),
01.. .... - SACCH,
other values are reserved.
As can be seen, CC bits in both DLCI and RSL Link Identifier
are coded differently. Therefore, we cannot just assign
one identifier to another, we need to do conversion.
I noticed that osmo-bsc indicates DLCI '01000011'B for SMS
messages sent over SACCH/F (SAPI3), and this is wrong because
'01'B is reserved. Let's fix this.
P.S. Interesting coincidence: section 9.3.2 in both documents.
Change-Id: If4d479a54cad467f53b49065c1c435a4471ac7d2
Related: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716
During LCS development, I'm getting use count bugs and would like to see use
token strings to figure it out.
Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
To distinguish between the CN requiring a Complete Layer 3 response, or just
the BSC requiring a TA, allow recording a separate for-LCS paging reason.
Change-Id: Ib28d1599ae4e483727398859d07de4490fbc31f0
Allow starting a paging from elsewhere than a BSSMAP Paging Request. For
upcoming Location Services (LCS), a BSSLAP TA Request from the SMLC may require
triggering a Paging.
Change-Id: Iaff91584699d163bd1963927280ff3a8ddd43073
For LCS, I would like to add an enum indicating the paging reason. Instead of
modifying extremely many function signatures to pass the reason across all
levels of paging, introduce a struct combining these.
Change-Id: I27ca78fc6ff8ef1101554c0a8429e34945ca6f3c
This is the only place where the entire dtap header is passed, where
the split between SAPI and CHAN is done. Other places in osmo-bsc pass
around a link_id integer containing everything, so leaving that out of
the scope for this patch.
The gsm0406_dlci_sapi_name() API was introduced in libosmocore 1.3.0,
and osmo-bsc currently requires libosmocore 1.4.0, so it means we are
not further restricting libosmocore dependency here by using it.
Change-Id: Ib72e2bda46e39d1075e4270ac5fa51df2f418164
It does not make sense to set the bsc_subscr's LAC from a Paging Request,
especially since the paging code has loops that possibly kick off several
pagings.
At this point, there remains no code setting bsub->lac anywhere. We could set
it during rx of Complete Layer 3, but since there is no use for it besides a
vty dump, let's just drop the bsub->lac completely, and the vty dump of it.
Change-Id: Id017bd494d329b6fc254d7135b4074ac2b224d66
RF-locking: simply ask bsc_grace_allow_new_connection() at the start of
page_subscriber(). Before this patch, we would log an INFO of "Paging request
failed" when RF-locked, for each BTS. Instead log "RF-locked". (An upcoming
patch will introduce a LOG_PAGING() macro that will trivially add more log
context there, so not bothering now.)
Drop LAC condition: since Stefan introduced page_subscriber() starting 2018
Ic3c62ff0fccea586794ea4b3c275a0685cc9326e, matching a requested LAC to a
specific BTS is done *before* calling page_subscriber().
BTW: the msc->core_lac (config 'core-location-area-code') has not had an effect
on Paging maybe ever. I opened OS#4751.
Change-Id: Ic8696414a1db8f4b1be502d6434599f684746ed6
The MSC may at any time send a BSSMAP CommonID message via a
SCCP connection to inform us of the IMSI of the subscriber. Let's
make use of that information by associating a related bsc_subscr
and updating the identity of the bsc_subscr_conn_fsm for improved
logging / filtering.
Closes: OS#2969
Change-Id: I52c43fb940f0db796adf4c0adb2260321c721c39
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
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause
value to lchan.release.cause_rr.
In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause
value, these are unrelated. Store in new lchan.release.cause_rr instead. The
rsl_error_cause is apparently only used for logging, except for one place in
lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so
there should not be a functional difference by this fix.
Propagate the BSSMAP Clear Command cause to the RR Channel Release:
Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so
far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens
in bssmap_handle_clear_cmd().
Adjust event handling in gscon_fsm_allstate(); there, pass the cause to
gscon_release_lchans(). In gscon_release_lchans(), pass the cause to
gscon_release_lchan(), and then lchan_release(), which sets the new
lchan.release.cause_rr to the passed cause value.
As soon as the lchan FSM enters the proper state, it calls
gsm48_send_rr_release(). There, set the cause value in the encoded message to
lchan.release.cause_rr.
Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command
cause code for normal release, it just passes 0 which amounts to
GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc
always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this
patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from
osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC.
This means in practice that we will now see an error cause in RR Channel
Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For
changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates
to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id
I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc).
A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b
(osmo-ttcn3-hacks).
Related: SYS#4872
Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed
that osmo-bsc crashes with the following message:
Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376
The cause of this is a recently merged patch that calls conn_get_bts() during
assignment_fsm rate counter dispatch:
"Count assignment rates per BTS as well"
commit b5ccf09fc4
Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a
The root cause being that the assignment_fsm attempts to count an Assignment
event for a BTS after the lchan has already been released and disassociated
from the conn.
The assertion is found in conn_get_bts(), which is used in various places. In
fact, each caller is a potential DoS risk -- though most are in code paths that
are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the
relatively volatile presence of an lchan is not a good idea for osmo-bsc's
stability and error resilience.
- Change conn_get_bts() to return NULL in the lack of an lchan.
- Adjust all callers of conn_get_bts() to gracefully handle a NULL return val.
- Same for cgi_for_msc() and callers, closely related.
Here is a backtrace:
Program received signal SIGABRT
pwndbg> bt
0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376
0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758
0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325
0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257
0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260
0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291
0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953
0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6
0x0000555555b61bbe in _start ()
In the case of the assignment_fsm counter, we now miss a chance to increase a
BTS counter for a failed Assignment, but this is a separate problem. The main
point of this patch is that osmo-bsc must not crash.
Related: OS#4620, OS#4619
Patch-by: fixeria
Tweaked-by: neels
Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
The separate struct osmo_bsc_data is like another separate struct gsm_network
for no reason. It is labeled "per-BSC data". These days, all of this is a
single BSC and there will not be different sets of osmo_bsc_data.
Drop struct osmo_bsc_data, move its members directly into gsm_network.
Some places tested 'if (net->bsc_data)', which is always true. Modify those
cases to rather do checks like 'if (net->rf_ctrl)', which are also always true
AFAICT, to keep as much unmodified logic as possible in this patch.
Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
The BSC is the wrong network component to originate USSD messaging, as can be
seen in the hacks in the USSD code: for example, the BSC would send a CM
Service Accept message as if an MSC had accepted the connection, dispatch a
USSD and directly send some RR release message (without proper tear down
messaging like the lchan_fsm does these days). This made sense in the osmo-nitb
world, but by now we are aiming for solid 3GPP compliance. The BSC shall not
originate USSD messages.
Deprecate all VTY and CTRL commands related to USSD:
VTY
[no] bsc-welcome-text
[no] bsc-msc-lost-text
[no] bsc-grace-text
[no] missing-msc-text
(the commands with 'no' are ignored, without 'no' lead to an error)
CTRL
ussd-notify-v1
Drop (already unused) ussd.h.
Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code.
Drop "RF grace" notification, where osmo-bsc was able to notify active
subscribers that the RF was being turned off.
Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
We decode the mesage and print it to the log files at ERROR log level.
We also count it in the BSSMAP message counters. There is not much
else we could do about it.
Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore)
Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
"Paging request failed" message can be logged e.g. when we're already
paging this subscriber which means we get hundreds of these messages
in a perfectly normal situation. Let's demote this to INFO and adjust
the wording.
Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
We already have counters for Rx side, now we also count Tx side.
See comments in the msc_ctr_description array implementation for
the details.
Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
The Osmux CID obtained from the MSC is passed to the co-located BSC MGW
to configure the MSC-side MGW conn of a call leg.
Depends on: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de
Change-Id: I86e7e13fc7921e3209fb764c0e7797e7ec09b79e
For AoIP, the AoIP Transport Layer Address IE must be included in the Handover
Request Acknowledge message, so the MSC can send RTP to the right place. Add
this IE for AoIP.
Depends: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576 (libosmocore)
Depends: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Change-Id: Ia05e37da125eb6e7b7be9b974b73261bd72de1f4
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Originally merged as Change-Id I4c7499c8c866ea3ff7b1327edb3615d003d927d3,
reverted because the change broke voice calls. Re-submitting with the fix:
don't forget to set conn->assignment.requires_voice_stream.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I7513d2cbe8b695ba6f031ad11560c63a6535cf2d
osmo-mgw.git also includes fixes of the MGW endpoint FSM, for example
I92a9944acc96398acd6649f9c3c5badec5dd6dcc.
Depends: I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I03e6b48d9b0a5370310d5f56809259ff7909cf9d
At the moment the length field of the bssmap header is not parsed.
Instead the length is computed out of the known header length and the
number of bytes received. This is prone to error, lets make sure that
extranous data at the end of a message is ignored by parsing the bssmap
length correctly.
Change-Id: Idef2e783d2377a2ad1f697ea4d26491a32b3e549
Related: OS#3806
This commit breaks voice channel assignment. It results in the
Assignment Complete sent to the MSC for a voice lchan lacking
AoIP Transport Layer Address, Speech Version and Speech Codec.
Hence the MSC cannot complete the Assignment for a voice call.
Let's revisit this patch, test thoroughly and re-merge later.
This reverts commit 4d3a21269b.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may
ask for a TCH/H and a TCH/F at the same time and tell which of the two
types it prefers.
The process of channel allocation currently selects, based on the BTS,
MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H)
and then tries to allocate it. If that allocation fails, there is no way
to try the second choice and the assignment fails.
For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the
channel allocator will try TCH/F and if it fails (all TCH/F are
currently in use), then TCH/H is never tried.
Since the BSC currently only trys the first best codec/rate that is
supported it also ignores the preference.
Lets fix those problems by including the preference information and both
possible codec/rate settings into the channel allocation decision.
Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51
Related: OS#3503
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.
We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.
That in turn will make sure the MS/UE can return very quickly to
the LTE cell.
Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
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
Neels Hofmeyr
Pau Espin
Harald Welte
Philipp Maier
Vadim Yanitskiy
Martin Hauke
Sylvain Munaut
Neels Hofmeyr