Age | Commit message (Collapse) | Author | Files | Lines |
|
As soon as we have received an ETWS primary notification message from
the CBC, we should transmit it as "RR Application Information" to all
dedicated channels.
Change-Id: I913d0237cffdcb95037da8489acef5f32a7fc02e
|
|
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
|
|
Fix neighbor config to match OsmoBSC manual: implement the plan for neighbor
configuration that was so far only described in the manual without actually
being in operation.
This first allows re-using ARFCN+BSIC pairs in and across BSS.
So far the handover_start() code always looked for handover target cells across
*all* local cells, even if they were not listed as neighbors to a source cell.
Imply all cells as neighbors only as long as there are no explicit neighbors
configured. As soon as the first 'neighbor' line appears in a 'bts' config,
only the listed neighbors are regarded as handover target cells. (The
'neighbor-list' commands are not related to this, only the relatively new
'neighbor (bts|lac|cgi|...)' commands affect actual handover procedures.)
TTCN3 tests TC_ho_neighbor_config_1 thru _7 play through the various aspects of
neighbor configuration: both the legacy implicit all-cells-are-neighbors as
well as allowing only explicit neighbors by config.
Related: OS#4056
Related: osmo-ttcn3-hacks Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
Change-Id: I29bca59ab232eddc74e0d4698efb9c9992443983
|
|
The struct member struct bsc_msc_data->is_authenticated is set to true
permanently. This is a leftover from the sccplite implementation and can
be removed now.
Change-Id: I966a48b383c85345c92c9a1fec791150e96cd7b9
Related: OS#3112
|
|
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
|
|
Clarify some in-code comments.
Fix descriptions of some handover timers, which still talked of "MO" and "MT"
handover -- which we now call "inter-BSC out" or "inter-BSC in" instead.
Change-Id: I8429a830edd0325893ac90f22fcc05309617bd2d
|
|
Related: OS#3487
Change-Id: I1639efb2dbcca4f0e9c33a74f3067606ce5f4209
|
|
bsc_clear_request() is in fact used only within gsm_08_08.c, make it static to
that file.
Since the gscon FSM, "real" BSSMAP Clear are sent only by gscon_bssmap_clear().
bsc_clear_request() remains in use for legacy code paths in gsm_08_08.c:
- the bsc_filter, i.e. for IMSI filtering;
- in move_to_msc(), from handle_cc_setup(), a code path that is in fact not
entirely clear to me. It seems to be an old functionality to serve multiple
MSCs?
Both of which I personally haven't seen in use, are not tested and should
probably be completely removed.
For now contain legacy code in the static context.
Adjust comment.
Change-Id: Ic89d0afad42e4b11183a13d2dc6b7bbf0b822fd9
|
|
Old osmo-bsc-sccplite already supported this, but in the migration
over to libosmo-sigtran and to real 3GPP AoIP, this functionality
got lost.
We now create a UDP proxy socket. Any MGCP commands received via IPA
from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on
this socket. Any responses back from the MGW received on the UDP
socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA
multiplex.
Closes: OS#2536
Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
|
|
The library has the declarations since 2011, so it's time to
get them removed from here.
Depends: libosmocore d61d517a2e35f482519561bd325652ee7144679a
Change-Id: I5c8d02605a78c6792f616ad423b4491b83f42545
|
|
Having the helper makes it easier to read/find for transport type checks. It
will be ifurther re-used in forthcoming commits.
Change-Id: Ic0ee4c472e29ec3092049e5e23b744395613616d
|
|
Add a new VTY command "ccch load-indication-threshold <0-100>"
by which the user can configure the threshold after which the BTS
shall send CCCH LOAD IND. It used to be hard-coded to a
default value of 10.
Change-Id: I059fe4627438e26a06e00d84e342b736ab7af440
|
|
Change-Id: I3ad0cc4866d6210181cbafbab876e8028ad27540
|
|
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
|
|
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
|
|
Related: OS#2551
Depends on: libosmocore I28f83e2e32b9533c99e65ccc1562900ac2aec74e
Change-Id: I830e38cc1ffb8b6ebbe299567507160f19beb528
|
|
Change-Id: I30c485c022f2d55e0a004f69b2503da7f91ecb74
|
|
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I00c18b78573386145af71c4b39f7f22aec24579b
|
|
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
|
|
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
|
|
This reverts commit 94c9324fe07cd0ba1277278270c8979d949e49ec.
Multiple ttcn3 handover tests were broken due to this commit. Let's
merge this once all the other commits pertaining to that fix can be
merged as well.
Fixes: OS#3942
Change-Id: I01d93778fb19c601c21f99ec4d2a3ab8a4a48f67
|
|
This variable does not seem to be used anywere in OsmoBSC, seems to be a
remnant from OpenBSC times.
Change-Id: I5e4aa352fa5f16f6ff64738f25afd1a844fa4fcb
|
|
Let's better clean up old stuff before doing new implementation.
Change-Id: Id4e254a1c24831afaba9ab7b330d4e09a2474c8e
|
|
Move the HO_ST_WAIT_MGW_ENDPOINT_TO_MSC state up to right after the lchan is
done establishing. For AoIP, the local RTP address towards the MSC already
needs to be known before the Handover Request Acknowledge is sent, so the AoIP
Transport Layer Address IE can be included. This patch only modifies the
handover FSM, a subsequent patch adds the IE.
Change-Id: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff
|
|
During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the
Handover Request message. Actually parse this Chosen Encryption Algorithm IE.
Place the chosen algorithm and the CK into lchan_activate_info->encr so that
the new lchan will use the same ciphering on this new BSS as it did on the old
BSS.
Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
|
|
For intra-BSC handover, the previous encryption is copied from the old lchan,
which of course is not available during inter-BSC handover. Hence the lchan
activation info needs to include an explicit encryption information, and we
must not rely on the presence of the previous lchan to copy encryption
information from.
Add struct lchan_activate_info.encr to allow passing encryption info through
lchan_activate() without requiring a previous struct gsm_lchan to be present.
Instead of copying from the old lchan, always copy encryption info to
lchan_activate_info, and during activation, just before sending the Channel
Activation, copy the lchan_activate_info.encr to the new lchan.
This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which
obtains the encryption information from an intra-BSC-incoming Handover Request
message.
Related: OS#3842
Related: I5b269f50bd2092516bfdf87746196983d3ac49d1
Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
|
|
MGCP/SDP provides fmtp parameters in order to signal which of the two
available AMR framing modes (octet-aligned or bandwith-efficient) should
be used on the link between BSS and core network. osmo-bsc currently
does not set up this mode which means that the RTP packets from the BTS
are forwared without inspection/modification, which may lead to
malfunction when a BTS is using a framing mode that is not supported by
the other end.
- Add VTY option to setup the framing mode
- Generate related fmtp parameters in SDP
Depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Change-Id: If6d40b2407b87aad2227ea7f15533ef01a3771b3
Related OS#3807
|
|
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 4d3a21269b25e7164a94fa8ce3ad67ff80904aee.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
|
|
This way ipaccess utils can be built without requiring libosmo-sigtran.
Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
|
|
This commit aims at better ordering of content in order to get rid of
sigtran stuff in gsm_data. This way we can avoid requiring
libosmo-sigtran when building ipaccess utils.
Change-Id: I8941f059d6e4eb21a971d48d2b66c29ec3355a6d
|
|
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>
|
|
Change-Id: If9c705e9fe6dba9225f7dec045e790af7a875ee8
|
|
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
|
|
Change-Id: I7ef602c3ce086aecbc3ae3ae6d3fd33ad2b9f85c
|
|
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current
lchan's AMR configuration. However, conn->assignment.* values are only valid
during an ongoing assignment. Those values may be overwritten by any failed
Assignment attempt, at any time, and hence do not reflect the currently
assigned conn->lchan. Those realms must be kept separate.
The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most
sense to store these values in struct gsm_lchan once the lchan activation
succeeded.
Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during
lchan_activate().
In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*.
Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
|
|
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
|
|
Change-Id: Icd7fd6273396026c5fe2da600f35631b1bac1614
|
|
* use gsm0808_create_ass_compl2() to add BSS Status IE to Assignment
Complete message
* drop local helpers
Depends-on: (libosmocore) I547c6b8707123aa8c1ef636db88908df112d90a4
Change-Id: I6916928391667cd9c345becf00e7c8561846c295
Related: OS#2487
|
|
Related: OS#2487
Change-Id: I341f4ea172432b94e8e96919926a5fb6870c2a30
|
|
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
|
|
There could multiple reason for OML or RSL link towards BTS to be
dropped: ctrl command, vty, new link etc. Introduce "reason" parameter
to corresponding functions and log it on link drop to simplify
troubleshooting issues with more complex setups.
Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
|
|
(requested by pespin)
Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
|
|
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
|
|
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
|
|
According to 3GPP TS 08.58 ยง8.5.1 BCCH INFORMATION:
"If the Full BCCH information element is not included this indicates that
transmission of the indicated SYSTEM INFORMATION message shall be stopped."
However, some ipaccess nanoBTS firmware versions are known to not support
some SI elements and also to dislike receiving BCCH Information for those SI,
even if received with empty BCCH Information meaning they should not be used.
Upon receival of this kind of message, nanoBTS sends a Failure Report
with following text:
Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
This kind of issue only appears with some fw versions, since it's known
to work fine in other ones, so let's not disable this kind of mesage by
default on all BTs of type "nanobts".
Instead, add a VTY command that allows disabling this kind of message in
order to be able to operate those nanoBTS units.
Fixes: OS#3707
Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
|
|
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
|
|
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
|
|
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c
|
|
It is moved prior to its user in the header file.
Change-Id: I59f52401ba37b351ba3848e8e9ffb3b24c259496
|