Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Ib34c8e3fb51d067581aefa1c80f8be1f6db9512e
|
|
Change-Id: I4bc157bf296e28678de6d9c9823f91810132a58c
|
|
Move code using MDCX via MGCP into separate function to make adding
alternative MDCX variants easier.
Change-Id: I5fafa3b12a39c83bdf64e16e192dd2454d069cf4
Related: OS#3659
|
|
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
|
|
Change-Id: I3a708c3ba2271d9968daa264736411c9326fc404
|
|
In 'show bts' command only display details of GPRS MO if GPRS is
configured for this BTS.
Change-Id: I082a9fecfa337dff5342b79cca8144b0ceaab15d
|
|
Fixes: coverity scan CID#189459
Change-Id: Ib9c5e374b9c5c8f79eecf95c439a25b0f438e4e5
|
|
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
|
|
The commit acd29192deed0e1a243b35278b030bde7b1662b5
Change-Id Ifb9212fede2333ad68db94188b5cda4fcabe02f8
introduced a bad change to neighbor_ident.vty. Revert that bit.
Change-Id: I8b80be6daef73f5864ba9f294bf2134c8a76ddb5
|
|
The chan mode is figured out per-BTS, but may remain uninitialized. Rather log
info about the channel request, like further above.
Change-Id: I07b89b6101879fb7c070c87be9bd38cc05ffa0b1
|
|
Change-Id: I41c04cfedaae4da69a2bc7d50b1f7fe0e467e0fa
|
|
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
|
|
bssmap_handle_cipher_mode() had code paths doing "goto reject" without
setting a meaningful cause value.
Related: OS#3186
Change-Id: Ia608fa34a6a2d3035a66d05fbc38553ac5186804
|
|
Change-Id: I359caf1dd30f033c0b606040ccf27aa4c5a9d2c6
|
|
During the generation of the multirate configuration IE in the channel
activation message that is sent over RSL, all AMR rates except the
highest one are trimmed. This was to ensure that the multirate
configuration IE only contains one codec rate per active set. Lets fix
that and generate a proper IE with threshold and hysteresis values.
- extend lchan_mr_config so that it can generate a full multirate
configuration IE
Change-Id: I7f9f8e8d9e2724cbe3ce2f3599bc0e5185fd8453
Related: OS#3529
|
|
The vty already has a well working interface to configure the AMR
mode, threshold and hysteresis parameters. However there are no checks
yet to prevent against misconfiguration.
- Use gsm48_multirate_config() to perform a global check of the overall
configuration
- Add check AMR modes during input (order, duplicates)
Change-Id: I8b9f69b89a39bbf4800d9790f7abe43ce66aeb71
Related: OS#3529
|
|
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
|
|
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
|
|
The function gsm_bts_alloc() does set default values for the amr rates
for a newly allocated bts, but it does not populate the ms_mode and
bts_mode flags which contain hysteresis and threshold. Those values are
currently set to 0 by default, which does not make much sense. Lets
popluate some appropriate default values.
- Make sure that .mode .hysteresis and .threshold are populated for
MS and BTS in full and halfrate
Change-Id: If14843feeeea6584e5991d5c0abb765611dfaa57
Related: OS#3529
|
|
Implement basic support for inter-BSC HO from handover_decision_2: do inter-BSC
handover only when rxlev / rxqual / ta drop below the minimum requirements.
I considered adding a vty config flag to disable/enable remote-BSS handover,
but to avoid inter-BSC HO the user can simply refrain from configuring
neighbors for a particular cell.
In collect_assignment_candidate(), it is important to clear out any new
candidate entry. Hence adopt the same pattern as below: first compose a new
(cleared) candidate, then write the entry into the list.
Related: OS#3638
Change-Id: Id78ac1b2016998a2931a23d62ec7a3f37bb764c6
|
|
a) Prepare for triggering handover for any candidate, remote or local.
b) drop redundant arguments.
Change-Id: I5ba8b556703010c8e232b516285a837c999f87ef
|
|
Change-Id: I56ec149979572486b904fc1409cf3cd096b6eb34
Fixes: Coverity CID#188867
|
|
Change-Id: I653ae9ede578370b4d7b1a150e9ec3c0702bbb31
Fixes: Coverity CID#188862
|
|
Change-Id: Id0eca3dd729d2e4c8c6ff83f05efde00b42c16f1
Fixes: Coverity CID#188860
|
|
We can only send a reject response if we have a valid conn.
Change-Id: I0ea535f494173ad4996c70dc82d7f69455e4e15e
Fixes: Coverity CID#188824
|
|
open() returning 0 is valid, but negative values indicate errors.
Change-Id: Id7e62116bfee550ef9906e78a0fce6f28af27a97
Fixes: Coverity CID#57865
|
|
When COMPLETE LAYER 3 INFORMATION is generated, it may include a speech
codec list that contains 0 elements (which is legal). The specification
requires the speech to be include if the network supports an IP based
user plane interface. It could be argumented that if no codecs are
available, the ip based user plane interface is not supported and
therefore the spec does not require the speech codec list IE to be
included for those cases. Lets check if the speech codec list has 0
elements and if its zero length, lets omit it completely.
- check for zero length speech codec list.
- omit speech codec list if it has zero elements
Change-Id: I07339322a71376e986a2d75b7bc1f552eafd02b5
Related: OS#3657
|
|
This only afffects a log statement, so not really an issue.
Change-Id: I8e5b164194855f78a266c1a4441730cc6c378d11
Fixes: Coverity CID#188829
|
|
Change-Id: I5bbb10af8b8e8ebc22bf79f5468e71a41b5e74b3
Fixes: Coverity CID#182710
|
|
The COMPLETE LAYER 3 INFORMATION message contains a an Codec List (BSS
Supported). When generating the compl l3 info msg, we check if the
speech codec list that we have generated before has at least one
element. If it has 0 elements we abort immediately. However, speech
codec lists with 0 elements are permitted by the spec, so we should
remove the checks as there are corner cases where voice support is
intentionally unavailable.
- Remove check for zero length speech codec lists.
Change-Id: Id7332e5273ff0efb85043dd1e1bb804cfe2db944
Depends: libosmocore I1eb1f4466b98bdd26d765b0e4cc690b5e89e9dd6
Related: OS#3657
|
|
This quickly allows knowing which IP a BTS is using in order to SSH
into it. Example output:
OsmoBSC> show trx
...
Baseband Transceiver NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
ip.access stream ID: 0x00 (r=192.168.1.178:34090<->l=192.168.1.37:3003)
...
OsmoBSC> show bts
...
Paging: 0 pending requests, 50 free slots
OML Link: (r=192.168.1.178:57692<->l=192.168.1.37:3002)
OML Link state: connected 0 days 0 hours 0 min. 17 sec.
...
Related: OS#3145
Change-Id: I37f020fcdb68cafcdbdb621808483d1dd996354f
|
|
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
|
|
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I7621616c24588c2db15ad1ae7ca68cfa0fb76f66
|
|
No functional change.
Change-Id: Ida186946f40d30f4d9ed94d9c1ff9bdb70048626
|
|
Don't goto the function end just to log something. Rather log right away and
exit early.
Change-Id: I6558a6948e8973cc91dae240375af074a5f5547e
|
|
Use a common LOGPHOCAND() to transparently log both local and remote
candidates.
Change-Id: I694e3832c55b4e972e05422e5e4508a74a222a71
|
|
Change-Id: I8bae3431dfaf23301e72f8f572286753b63a99b9
|
|
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
|
|
Fix copy-paste error that resulted in counting outgoing inter-BSC HOs as
incoming ones.
Change-Id: I188b5db9e98c76153fdfb6f864d2cbfaea77bd5d
|
|
Change-Id: Ibe977a92acb93a78e323a40f53d653059b07bc0f
|
|
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
|
|
Change-Id: I111c7f14e5f70ecbf6c660c1de24c6a5796b2eef
Closes: OS#3630
|
|
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
|