I believe I have initially misinterpreted the idea behind sending a Cell
Identifier List in BSSMAP Handover Required messages. Instead of associating N
Cell Identifiers with one ARFCN+BSIC, the idea is to add up N separate
ARFCN+BSIC's Cell Identifiers into a list. To keep the door open for future
code simplification, make sure to allow only one Cell Identifier per remote
ARFCN+BSIC on the VTY UI.
Related: OS#3656
Change-Id: Ifb9212fede2333ad68db94188b5cda4fcabe02f8
Inter-BSC outgoing lacked the required BSSMAP HO Failure dispatch.
Not all cases should send BSSMAP HO Failure, name the relevant spec paragraphs
in comments and adjust handling.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I0980cacb9713e41a1eef3a0a7f6cc892e8a20da5
Usually, conn->lchan is set to NULL before/upon releasing it. However, if the
lchan is still associated with a conn upon/after release, make sure the conn
realizes it has no lchan and sends a BSSMAP Clear Request to the MSC.
lchan_reset() is the last step before an lchan is fully unused. In there, make
sure to notify any conn that might still be associated, with
gscon_forget_lchan().
lchan_cleanup() does the same, but in fact this is only called when an lchan is
*deallocated*, but instead it usually merely goes to the UNUSED state.
It may make sense to call gscon_forget_lchan() sooner, e.g. when entering a
releasing state. This here nevertheless is a final safeguard.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I88337a18246c44ba48da64bb611a3cbb647a750e
Clear all lchan->conn pointers when the subscr conn code is choosing to release
an lchan, with gscon_release_lchan().
Rationale: when an lchan releases in error, it should trigger the conn to be
notified and cause a BSSMAP Clear. However, if the conn is actively requesting
for an lchan release, it is already taking care of the situation.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Send a BSSMAP Clear Request only if absolutely no lchan remains associated to
the conn, anywhere (Assignment, Handover as well as primary lchan).
Conceivable would be a situation where e.g. we're in handover and a new lchan
is ready, when just at a time where it doesn't matter anymore the old lchan
fails. We could just carry on with the new one then.
Change-Id: Ibd8e38ccf7759b8834efdedf742c46c227b26e91
Send a BSSMAP Clear Request only if we are not already in ST_CLEARING, i.e.
haven't received a BSSMAP Clear Command yet.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: Idc749068580da45e821e0af04cfa14cc7ce5c432
At the moment codec_pref only checks the codec configuration, but it
does not check if there is actually a matching physical channel
available. This should be checked too we must make sure that the codec
we select fits the physical channels available on the BTS.
Change-Id: I2d29dfed450e5ef93c26ed5ec9fdc0730eb3d7dd
Related: OS#3503
The function match_codec_pref determines whether a permitted speech
value belongs to a half-rate or full-rate codec. Lets seperate this into
a separate function.
Change-Id: Iec1db4621ba5a09bc0e3fc40b66f3a3bc5f54add
Related: OS#3503
In networks with a couple of different BTSs it may be likely that one
accidently sets up a codec configuration (codec-support)) that will be
mutually exclusive towards the codec configuration for the MSC
(codec-list). We need a check that validates the configuration before
start to catch such configuration flaws quickly.
- Add a check that checks each MSC codec-list against each BTS
codec-support setting.
Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38
Related: OS#3625
When the user sets no codec-list in the msc node, the configuration will
end up with an empty codec list. This is a useless configuration. There
should be a sane default setting.
- Set all possible codecs as default for codec-list
Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed
Related: OS#3625
The COMPLETE LAYER 3 INFORMATION message should contain a Codec List
(BSS Supported) IE. The contents of this list depend on the BTS
capabilities and of the MSC configuration (allowed codecs). There may
be cases where (due to miss-configuration) the list is empty. In those
cases the BSC hits an assertion because the encoding of the overall
message fails when the codec list is empty. A check is needed.
- Check codec list before message generation, abort if the coded
list is empty.
Change-Id: I119607047a132b75b3077bbe56c97936d8ae6c96
Related: OS#3625
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
main() was missing a call to rate_ctr_init(). Without it, the counters
increased properly, but the times per second / minute / hour etc. values
would always stay at zero.
Change-Id: I4466a7aec51673c79b67614c9dde987633e379e0
Related: OS#3579
Seen while operating a setup with 2 TRX (2 nanobts):
DNM <0004> abis_nm.c:703 OC=CHANNEL(03) INST=(00,01,04): bts=0 trx=0 Opstart ACK
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Received Event TS_EV_OML_READY
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Event TS_EV_OML_READY not permitte
As it can be seen, OML log header state correctly it comes from TRX1,
but later content in line expresses TRX0, and that failure is forwarded
up the stack and channels for TRX different than TRX0 are never
initialized.
Related: OS#3560
Fixes: f0ff9a6711
Change-Id: I27e992e419422051247777b048175b724c05323e
After commit https://gerrit.osmocom.org/#/c/libosmo-abis/+/11207/
(Iaa33b793f89f2d16c9d949503c5ecc195bbcd2a4),
input_signal_data->link_type exposes proper enum type, and compiler can
warn about missing cases:
osmo-bsc/bts_ericsson_rbs2000.c: In function ‘inp_sig_cb’:
osmo-bsc/bts_ericsson_rbs2000.c:124:3: error: enumeration value ‘E1INP_SIGN_NONE’ not handled in switch [-Werror=switch]
switch (isd->link_type) {
^~~~~~
Change-Id: Ia407a5072896377b68e914e2a05b5e01292ee8ee
Add missing item in the landscape of VTY commands: allow identifying a local
cell by CGI (besides BTS nr, LAC or LAC+CI, which already exist).
Change-Id: I2d03de6b695904c4a86025bf250358d04f6e47de
When writing the neighbor configuration documentation, I noticed that 'neighbor
add' and 'neighbor del' make sense from an interactive VTY POV, but when
looking at a static config file, it makes more sense to simply name the
neighbors without the 'add' keyword, and to use the 'no' prefix instead of the
'del' keyword. It still makes sense to tweak cosmetics like this before
inter-bsc handover is used anywhere.
First, remove 'add' from all 'neighbor add ...' commands.
Instead, prepend "Add" to the doc string for the cell identification argument
in commands that add a neighbor:
-OsmoBSC(config-net-bts)# neighbor add ?
- bts Neighbor cell by local BTS number
+OsmoBSC(config-net-bts)# neighbor ?
+ bts Add Neighbor cell by local BTS number
(A subsequent patch will rename 'neighbor del' to 'no neighbor'.)
Change-Id: I143f21f6069d1a86096cc8240cf69eb7ea9c8ac8
After previous patch I8dd561d744d8081b5ac5ffa7635f17ac19bcda45, all callers
pass conn->lchan to send_assignment_complete(), so there is no need to pass it
separately from conn.
Change-Id: I3c038d91a53c81d9fcf4ec62f853b59bb1ecd244
In assignment_success(), don't trigger lcls_apply_config() before the
conn->lchan points at the actual new voice lchan. The entire LCLS code relies
on conn->lchan.
The assignment FSM wants to point conn->lchan to the new lchan only after it is
sure that sending the Assignment Complete to the MSC was successful. However, a
failure is a) very unlikely and b) if sending to the MSC fails we might as well
tear the whole conn down anyway. Now, if sending to the MSC fails, release the
lchan and the conn should clean itself up.
Related: OS#1602
Change-Id: I8dd561d744d8081b5ac5ffa7635f17ac19bcda45
When a codec mismatch (lchan type or tch_mode does not match) occurs, we
do not know which of the two lchan had which type or tch_mode. Lets
print that information as well to make debugging easier.
Change-Id: I3fd22fef50d8944ca8c003c6114fdda37417b2ea
Related: OS#1602
In rf_create_socket(), check the result of osmo_strlcpy().
This catches overlong and non-NUL-terminated socket paths.
Change-Id: I4b9ff9146068bf7f53d67c577454f32c02361b86
Related: OS#2673
The COMPLETE LAYER 3 INFORMATION message lacks the Codec List (BSS Supported)
information element. This information element is mandatory for networks
that use an IP based user plane (AoIP).
- Add function to generate the speech codec list from the current codec
settings (Available codecs)
- Generate and embed information element in L3 Compl. message
Depends: libosmocore I4e656731b16621736c7a2f4e64d9ce63b1064e98
Change-Id: Id6f2af3fdab45bf05f06aec03e222734d7a4cf70
Related: OS#3548
At the moment we do not initalize the struct members mr_full and mr_half
in struct gsm_bts. The user still has the option to configure reasonable
values via vty, but when not VTY configuration is made, the flags for
the AMR rates will be all zero. Lets initalize the struct members with
reasonable defaults.
- Make sure gsm_bts_alloc() populates fr_half and fr_full with
reasonable defaults.
Change-Id: I68747ae6dd2582e2a7d60337d9f2c43bd06ac525
Related: OS#3548
The field speech codec (choosen) in the ASSIGNMENT COMPLETE message
has been specified with AoIP. Since sccp-lite has been specified before
AoIP, we should not include the speech codec (choosen) field in the
ASSIGNMENT COMPLETE, when osmo-bsc is connected to an sccp-lite based
network.
- make sure speech codec (choosen) is only included on AoIP based
networks
Change-Id: Ic7f28aacc953d96ebf3aa04f3e1810475458c1a8
If the MSC sends a BSSMAP Classmark Request, send an RR Classmark Enquiry to
the MS.
(The reverse direction, i.e. sending a BSSMAP Classmark Update back to the MSC,
is already implemented.)
Related: OS#3043 (A5/3 encryption)
Related: osmo-ttcn3-hacks Idaab4d568cf986b4897ba008f6262c839d1592fb
Change-Id: If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf
Remove unused gsm_subscriber_connection.user_plane.chan_mode.
There is only one VTY command that displays it along other
parameters, but it is used no where else. Lets remove it.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I10049c14ea206a4daafbdad01634d57c72a79d7c
Remove unused member gsm_subscriber_connection.user_plane.full_rate.
It was forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
change-id I82e3f918295daa83274a4cf803f046979f284366
Change-Id: I3a14efe0039ff4690e27e3b083eb23c1b2a616c3
gsm_subscriber_connection.user_plane.chan_mode and .full_rate were unused
since and forgotten to be removed in:
commit 31f525e756
Date Mon May 14 18:14:15 2018 +0200
"large refactoring: use FSMs for lchans; add inter-BSC HO"
Instead of above unused struct members, use lchan->{full_rate,tch_mode}.
When not explicitly allowed via VTY settings, the LCLS mechanisms will
avoid to locally switch connections with different codecs/rates. For
example GSM HR and GSM FR would not be locally switched.
Change-Id: Idd7117092b1f170d5029303ae5ba0a49e02a8bfb
Related: OS#1602
In function test_codec_support_bts() the switch case statement lacks
break; statements for some cases. This may lead into messed up codec
decisions.
- Add missing break statements
Change-Id: Ib5400a0a0a8a39fa714bd087df345160bed5cc61
The the function make_scl_config() is used to generate realistically
looking speech codec lists to perform the unit tests for codec_pref.c.
This function does not yet populate the S0-S15 bits for AMR codecs. Lets
make sure that at least the default configuration is populated here.
Change-Id: I534239416c038ea856c128659f314aa521f85c15
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
Neels Hofmeyr
Daniel Willmann
Philipp Maier
Harald Welte
Oliver Smith
Pau Espin
Martin Hauke