Remove "Helper function for match_codec_pref()" at the beginning of the
descriptions of these functions, looks like a leftover from before this
was moved to its own c file. Remove a duplicated "received" in a
comment.
Change-Id: I30f0744db9aebf2f05077fef840097c332b9dafd
tall_ctr_ctx is not defined or used in osmo-bsc and apparently was only
exported by accident from libosmocore. It's not exported anymore since
libosmocore.map was introduced in I13169c00a59fb59513dfc598de5a71d094492422.
Fix for:
/usr/bin/ld: osmo_bsc_main.o: in function `main':
osmo_bsc_main.c:(.text+0x830d): undefined reference to `tall_ctr_ctx'
/usr/bin/ld: osmo_bsc_main.c:(.text+0x8331): undefined reference to `tall_ctr_ctx'
Change-Id: I558e1ec722f3b1ff1f2e89b3cb97ed1dba9063e3
T23042 was a placeholder for timers to be filled in later. Replace it
with timers that can be configured via VTY.
Previous timeout for the states was 5s, from using the default of 5 for
undefined timers.
* ASSIGNMENT_ST_WAIT_MGW_ENDPOINT_TO_MSC and
HO_ST_WAIT_MGW_ENDPOINT_TO_MSC:
* Runs gscon_connect_mgw_to_msc() on enter, which waits for one MGCP
CRCX or MDCX response (or changes state immediately)
* Use existing X9 ("Timeout for availability of MGW endpoint"), 5s,
which is already being used by lchan_rtp_fsm for a similar purpose
* HO_ST_WAIT_RR_HO_DETECT:
* Handover initiation as described in 3GPP TS 04.08 § 3.4.4.1:
"The network initiates the handover procedure by sending a HANDOVER
COMMAND message to the mobile station on the main DCCH. It then
starts timer T3103."
* Use existing but unused timer T3103 ("Handover"), 5s
* HO_ST_WAIT_RR_HO_COMPLETE:
* Handover completion as described in 3GPP TS 04.08 § 3.4.4.3:
"When receiving the HANDOVER COMPLETE message, the network stops
timer T3103 and releases the old channels."
* Continue using T3103 with keep_timer = true
Closes: OS#5787
Change-Id: Id0d4d0788f609f3272fc81c80a754383dde25c16
Remove placeholder timer T23042. This handover fsm state waits for both
RSL/RR and RTP/MGW to be complete. I've added TTCN-3 tests to ensure
that both cases are covered by existing timer T3101 in lchan fsm state
LCHAN_ST_WAIT_RLL_RTP_ESTABLISH, which on timeout lets the handover
fail.
Related: OS#5787
Related: osmo-ttcn3-hacks I30e1811f97406cff6ba794fcd6882e2bb0205087
Related: osmo-ttcn3-hacks I2f79e3ff988a4315fbef3538f02403b818fa7839
Change-Id: I53468766c3c5fad7d7e275c0f20b5c20677fe4e8
Remove placeholder timer T23042.
Neels wrote:
> I think the right thing here is to remove this timeout; this needs
> no timeout at all because we can rely on the lchan_fsm to either
> return HO_EV_LCHAN_ACTIVE or HO_EV_LCHAN_ERROR after the usual
> timeouts set for lchan activation. IOW since it is internal to
> osmo-bsc one of the two events is guaranteed to occur.
>
> If we superimpose a timer on top of the lchan timeouts, configuring
> larger lchan activation timeouts becomes complex, because the user
> has to take care to also allow a larger timeout for the same
> procedure during HO.
Related: OS#5787
Change-Id: Ibf740aaa9bddc2de85cf8087ad90bab47aac12c2
In classic E1 based GSM networks the audio is usually transfered through
16bkps I.460 subslots while 4 16kbps subslots are multiplexed into one
E1 timeslot. However, there may be setups where still 16kbps subslots
are used, but with 1 instead of 4 channels per timeslot. In those cases
the bit offset is 0, while the rate is still 16kbps.
Change-Id: I0d2bc44acaa8e5a28cccfdf7cfb945bf14a4ed30
Related: OS#5198
osmo-bsc requires the PCU to tag IMMEDIATE ASSIGNMENTS that shall be
sent via PCU with a TLLI. This is required to confirm the sending of the
IMMEDIATE ASSIGNMENT messages to the PCU.
Related: OS#5198
Change-Id: Ib804143a57824632e5435f7ba68f2e94f5f3fb21
The BSC has all information about the E1 line configuration of each
timeslot/channel. The PCU is responsible for opening and managing the
CCU connection. To enable the CCU to do that, we have to transfer the E1
connection information (which TS, SS, rate) to the PCU.
Change-Id: I6d44373336b41009ff4c6e459d32d0a81081676c
Related: OS#5198
The PCU needs to be aware of the current system information in order to
work properly.
Change-Id: Ibbfbfaf588a4e406804c36570010aefdfc14328b
Related: OS#5198
We have introduced the function extract_paging_group() with the previous
patch. Lets use it for PCU_IF_SAPI_PCH as well to remove code
duplication
Change-Id: If4ffe8eafd2e54e323cbc075c09d457a74ebe83f
Related: OS#5198
The IMMEDIATE ASSIGNMENT for downlink TBFs needs to be sent through the
PCH instead of the AGCH. Since this method is not specified in RSL, it
is usually a vendor specific extension.
Change-Id: I4452f4973d1ec69c96aad527b057226e8a6edf99
Related: OS#5198
The current name of PCU_IF_SAPI_AGCH_DT is a bit misleading as it
describes a method to send immediate assignment messages (normally AGCH)
via the PCH. The name in the constant should reflect that correctly
Change-Id: I78abeb62d0267baa31a4727c4bdd027b7230f137
Related: OS#5198
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-bsc. In the example below:
network
network country code 901
mobile network code 70
...
mgw 0
remote-ip 127.0.0.1
local-ip 127.0.0.1
periodic location update 30
the 'periodic location update 30' will trigger a segfault:
(gdb) bt
#0 0x00005555555dfc09 in cfg_net_per_loc_upd ()
#1 0x00007ffff7af6c3f in cmd_execute_command_strict () from /usr/local/lib/libosmovty.so.9
#2 0x00007ffff7af6f1c in config_from_file () from /usr/local/lib/libosmovty.so.9
#3 0x00007ffff7afd4e1 in vty_read_config_filep () from /usr/local/lib/libosmovty.so.9
#4 0x00007ffff7afe375 in vty_read_config_file () from /usr/local/lib/libosmovty.so.9
#5 0x0000555555579616 in bsc_network_configure ()
#6 0x000055555557a352 in main ()
because vty->index would be NULL after returning from the MGW node.
Fix this by adding the missing case to bsc_vty_go_parent().
Change-Id: Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
Fixes: [1] 8d22e68706
The intended endienaess for the remote_port member is host byte order,
while the endianess in the nsvc struct is in network byte order.
(see also pcu_sock.c in osmo-bts.git)
Change-Id: Ib62dcceb80fd500e477dd5e1a0e43de47e16eeb0
Related: OS#5198
The Ericsson RBS is a BTS that natively works with dynamic timeslots.
This colides with the current understanding of static PDCH channels
because the BTSs we support so far get thier static PDCH information on
startup and then handle everything related internally. The BSC does not
actively manage the channel in those cases. In the case of Ericsson we
have to activate the PDCH via RSL like any other channel and the timeslot
FSM has to manage it. Lets not add work arouds for this, lets just print
and error message and use the BTS in the dynamic scheme as intended by
the manufacturer.
Change-Id: Icc7c2956fc934691e3bfacb283d896a8767baf27
Related: OS#5198
Before filling in the TS in the info indication, it is checked that the
MO opstate is enabled. Also it is checked that the TS serves a PDCH.
Lets restructure this check and move the PDCH check into a helper
function as we need to check for PDCH from other location as well later.
Change-Id: Icaab52ab73c38889dfadb523b89bb54cafacc99a
Related: OS#5198
We send the TS_EV_OML_READY event early, even though the TRX is not
fully done with all OML initialization steps. Lets complete the TRX
initialization first and then notify each timeslot FSM with
TS_EV_OML_READY.
Change-Id: If5251b102c8aa45dfc8cc4ee4e0223d7dc438938
Make sure that the TRX MO state is enabled and unlocked before filling
in any TRX information into the info indication
Change-Id: I7a93826e6b0df187425310cb82854e7d7fb47e72
Related: OS#5198
Make 'apply-config-file' check the neighbor config, just as is done after config parsing on startup
Related: OS#5866
Change-Id: I24ae8cd7e5e0d15eab9fd04b1858072bf0bad36a
The function pcu_tx_info_ind() fills the trx information in the info
indication. Since the function is already quite long, move the trx
related part into a sperate helper function.
Change-Id: Ic30185c9364adcc61d0a9d3483b0550ac1cdf894
Related: OS#5198
The pcuif only supports a limited but sufficient number of TRXs. When
filling in the TRX array in info_ind, we must guard against overflowing
the maximum number of TRXs
Change-Id: I351080a112f3d3fdf833ee7fa0d77c4cd1d13e42
Related: OS#5198
The formula that is used to recover the (relative) frame number from the
T1, T2, T3 parameters matches the definition in the spec, but since the
partial term t3-t2 can be negative special precaution is required when
performing the MOD 26 operation. This is due to the truncated modulo
implementation in C/C++, which has a very specific understanding on how
to deal with negative input parameters.
The libosmocore gsm_gsmtime2fn(() offers a correct implementation, so
lets use it.
Change-Id: I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Related: OS#5198
The function trx_get_hlayer1() is defined as a prototype but it is not
used anywhere and there is also no implementation, lets drop it.
Related: OS#5198
Change-Id: I91ead9379140e971ccabc83cbf2b62b8aa1fc8a2
The (relative) frame number that is forwarded to the PCU is an
important parameter which is computed from t1,t3,t2.
Change-Id: I83d20ba9e0ce6488d458ccf4a85c8445c30e3a89
When a CHAN RQD is received via RSL, we show ra and other parameters.
Lets also show T1, T3 and T2.
Change-Id: I78499b49ae176b736e384e193fadc0bdd669dffa
The frame number calculation in rsl_rx_pchan_rqd() is done using a
specific formula. Lets add a spec reference and also restructure the
code a bit.
Change-Id: I60500c8694dbc2e6e2c4bbffd4ff7057bbc324e6
TTCN3 have been improved in osmo-ttcn3-hacks.git Change-Id
I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54 to use valid l3 data.
Related: SYS#6280
Change-Id: I4918f1741d465abf8b06a9c65199a44b09778299
IMEI may be used as MobileIdentity during MO emergency call
establishment if the MS has no valid IMSI assigned.
Related: OS#5849
Change-Id: I586b1ee30cbb26ddf58788168d56c962e03ccd5c
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
It was found in a BSC on the field that an MS sending an incorrect
MobileIdentity IE (wrong length) in PagingResponse was generating a
crash on the BSC.
When the MobileIdentity cannot be parsed right now we keep on instead of
rejecting the conn. This should change in the future, but it needs
further improvements in our TTCN3 tests. For now let's simply validate
the subscriber is not NULL; since recently paging optimizations made
paging_request_stop() require the subscriber to be non-null.
Fixes: 27cb5d3e24
Related: SYS#6280
Change-Id: If8b439ff74c5dd690d637d3e3278c75d6cd6b928
In send_assignment_complete(), obviously return the current channel
configuration from lchan->current_ch_mode_rate, which is the proper
place to get the channel mode after RSL Chan Activ Ack.
It is interesting to look at the history of this line of code.
lchan->current_ch_mode_rate was added later, so now the mistake is very
obvious.
Related: SYS#6229
Change-Id: I3bf8f5ea9ae2a3c12fc5b483818d550a069fe66e
This patch caches the counts of initial paging requests for each paging
group. This count is needed to estimate T3113 when a new incoming paging
request is received and it has to be inserted into the queue.
With this there's no need to traverse the whole initial_req_list every
time a new incoming paging request is receiving, potentially saving lots
of iteration and hence lots of CPU when the queue is long.
Related: SYS#6200
Change-Id: I6994127827d120a0b4dd3de51e1ddde39f2fe531
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
When adding a new incoming request (aka "initial_req"), if the queue is
full only of retransmis (no not-yet-ever-transmitted initial requests
queued), then the new incoming request is inserted at the start of the
queue, in order to take scheduling priority over retransmits.
This was already fine before this patch, but the counting of requests
before it (used to calculate its T3113) was wrong, because it counted all
the retransmissions. This patch fixes it to end up with
reqs_before(_same_group)=0.
Change-Id: Ib2e810b0bcc51eac117713584310272462c58867
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
The default is to have a dynamic T3113. However, if the user wished to
set it statically, it would show up when writing the current VTY config.
Change-Id: If121a97bbb4a0234a0c162ef37c3692d6408404d
The BTS can be obtained easily from the backpointer in req->bts. Having
the extra param can only lead to confusion and introduction of bugs, as
happened in bug fixed by Change-Id
I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679.
Related: SYS#6200
Change-Id: I545fd853fdffce7f23f0d99203c66c3b39144e4b
When rewriting the loop, the pointer passed all the time to
paging_remove_request() was the one of the BTS which answered the
request, not the one actually handling the related unanwared still
active paging request.
Fixes: 70a1d60a83
Related: SYS#6200
Change-Id: I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679
This allows tracking each BTS active paging request queue length over
time, and evaluate CPU load based on the number of active paging
requests queued.
Related: SYS#6200
Change-Id: I6d296cdeba1392ef95fc31f6c04210c73f1b23e5
This way all paging related stats can be grouped (more will be added in
follow-up commits).
Related: SYS#6200
Change-Id: Iede1b6f68df468c7a3b3bf5fce7f68bb08b78832
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Neels wrote:
> i guess we can drop this comment now, it is a remnant from separating
> osmo-nitb -> osmo-bsc + osmo-ms
Change-Id: I2ce4d691715c1ea5c7c7896693a03b0aefbdb5b9
Prior to this patch the whole paging queue of each BTS was iterated.
After the patch only the active paging_req for a given subscriber are
iterated.
Related: SYS#6200
Change-Id: I225d5e08427c6bb9d92ce6a1dccb6ce36053eab5
This is triggered by BSC_Tests.TC_lcs_loc_req_no_subscriber.
Before, the NULL ptr was not a problem because paging_request_cancel()
only used the pointer to compare it against other pointers, but never
accessing it. A follow-up patch is, however, changing the implementation
to optimize the lookup by using the subscriber pointer, which generates
a crash.
Related: SYS#6200
Change-Id: Id0de43ac5bde0f52f258de6c9bf58b173301c8db
Before this patch, the entire queue of paging_request had to be iterated
in order to find if the subscriber already had an active paging request
(discarding duplicates).
Now that bsc_subscriber holds a list of its active paging requests, it's
easier to look at its list to find out if it is already active on that
BTS.
As a result, there's no need to unconditionally iterate the whole list
and we can optimize the loop finding the spot to insert the new queue:
- First the potentially way smaller loop over
bsub->active_paging_requests is done
- Second, only if the first loop allowed, the bts->pending_requests is
iterated and potentially early terminated.
Related: SYS#6200
Change-Id: I7912275026c4d4983269c8870aa5565c93277c5a
This allows havily decreasing the algorithmic cost of removing all
pending active paging requests for a given subscriber once it answers
on a given BTS.
Beforehand, the whole paging queue of all BTS were iterated. Now, only
the active requests for that subscriber are iterated.
Related: SYS#6200
Change-Id: I831d0fe01d7812c34500362b90f47cd65645b666
This saves the BSC from iterating twice the whole paging list of the BTS
which received the paging response.
Related: SYS#6200
Change-Id: I5f9215f31428ce0249cd9ece6d2d4e93155f429f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
The function rsl_ericsson_imm_assign_cmd has a comment "Chapter 8.5.6"
above it. However, thats only half true. The function implements
ericsson vendor specific RSL IEs, so lets be more clear about this in
the spec reference.
Change-Id: Id27662e208ca8ac0a48851583c11fbacf85f988c
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
This feature allows pinning each BTS to a specific MGW from the
configured pool. The pinning can be soft or hard (strict). If strict
pinning is not set, the configured MGW is selected with priority, but
other MGWs can still be selected during each call setup if the
preferred MGW is found not available at that time, hence avoiding denial
of service for the entire BTS if that MGW goes down.
If strict mode is selected, the call will be refused if the configured
preferred MGW is not available at the time the call is set up.
It is useful to use this feature when Osmux is configured between
the BTS and the BSC and an MGW pool is in use. This way the BSC is
capable of grouping all the calls of a BTS towards one MGW, hence taking
advantage of the Osmux trunking optimizations to reduce link data usage
(AMR payload of several concurrent calls ending up sharing the same
underlaying UPD packet).
Furthermore, this allows the operator to intelligently spread load over
the MGW pool in order to avoid ending up with more than 256 concurrent
Osmux circuits on any of the co-located MGWs in the pool (maximum supported
at the moment).
Related: SYS#5987
Depends: osmo-mgw.git 5d8b5b093595e1203e288c3175c163c0994b1102
Change-Id: I9a7a5af72795faed0d12d9d73b59951b6a0e9c7d
The CHAN REQ entry is not deleted after its information was passed on to
the PCU. This causes the same entry to be used over and over again while
blocking other incoming CHAN RQD.
Change-Id: Ia4abc55fc6fcb1c00991cc84d09529131d014910
Related: OS#5198
There's no need to fail, simply make it a noop in that case,
everything's fine and everybody is happy (specially when using CTRL
command "apply-config-file" to load a .cfg file containing
modifications.
Related: SYS#6138
Change-Id: Ia4e70d20d48a28c46a21dd10358577e5c798744c
Current organization is totally mess, there's actually no organization
at all for lots of commands.
Let's organize most commands based on CTRL node where they are applied:
global, bts, trx, etc.
Specific set of commands such as neighbor-related, rf-related, etc.
are left in separate files as subsections inside the same node, so the
hierarchy is still clear.
Change-Id: I51a9b31780a4a8026aafb2d732369cdc10c8bb70
There exists a VTY command for sending default power control params,
but so far there was no CTRL counterpart for it. This patch adds a
SET command 'send-power-control-defaults':
$ osmo_ctrl.py \
--host 127.0.0.1 -p 4249 \
--set "bts.0.send-power-control-defaults" 1
Similar to 'send-new-system-informations', this command takes an
arbitrary dummy value (required for SET), which is simply ignored.
Change-Id: Ib370bd97ee2d9f72f8bec553550b1792d1345387
Related: SYS#6138
in osmo-pcu, the message buffer in pcu_sock_read is allocated with 1000
bytes in addition to the true size of the pcu_prim struct. Presumably
this is to avoid compatibility problems in case the primitives slightly
grow due to appending new struct members. Lets do the same in osmo-bts.
Change-Id: I99f5204b0563f72f9da427bb7aa5451552d8c5b5
Related: OS#5198
The pcu_sock interface in osmo-bts does check the size of the primitives
it receives. Lets do the same in osmo-bsc as well.
Change-Id: I247c6f4b5a7a22d17a060a558c4ceb9221ca7351
Related: OS#5198
We expect osmo-bts to provide us with a remote CID in order to be able
to set up MGW to send Osmux frames to it.
Related: SYS#5987
Change-Id: Ia90e8e0d18193d64c0fa0788dbd0eb242a359b61
the shared code in libbsc checks for sane config being set, but this
doesn't really apply to ipaccess-config, wihich doesn't set such config
fields internally.
Change-Id: I22ff0d22d6dcf9b0f715bfa4e0daeb52c4028308
Until now Osmux was selected unconditionally in bss-side CRCX, without
checking if the codec was AMR or not. If Osmux use policy is "on", we
only want to request Osmux use if AMR codec is selected.
Change-Id: I3f53555dd9608f1337365e4f82b492bdf1da05bb
ipaccess-config sets up the entire line in a fake way.
That requires also setting the fd of each TS used to -1 in order to
avoid library code interacting with it during tear down if an error
occurs.
Change-Id: I19eb23a46f89b96dd8d63742ca2078ecd5c9ab6b
Since this is created by osmo-bsc, it is also expected to be there by
ipaccess_drop_oml() in the shared libbsc code. But ipaccess-config was
not creating it, so let's do so.
Let's explicitly assert this condition in the code path expecting the
pointer to be instantiated in shared code, to easily track related
issues in the future.
Change-Id: I3f63f6827f7c5d7a21ac125b7ca6b35244efbb65
nanoBTS waits until receiving OPSTART in order to establish the RSL
connection socket against BSC, hence we cannot wait until the socket is
established at the BSC in order to send the OPSTART.
Still this way we make sure the RSL CONNECT is acked before attempting
an OPSTART at the BSC.
Change-Id: Ief46bad5075b656c13d1f09a0724e33283148236
The LAC value currently configured is now printed as hexadecimal value
too.
It can still be entered as a decimal value in order to keep backward
compatibility, though the hexadecimal one is now preferred.
Related: OS#5631
Depends: libosmocore.git Ia2b7fbbf5502c28374c21dbff548232680da27d4
Change-Id: I9090d73ae9d39244b79b9dbafa1b164faebabc52
It makes no sense to have duplicate signals. Let's simply clean up
S_NM_IPACC_ACK and pass the required info for higher layers to do
whatever is needed based on the information.
This allows reusing same signal infrastructure for different types of
messages instead of having to implement new signals for each message
(which can be done at a higher point in the stack).
Change-Id: I18ae3d320d00077fc13bb9903903de2a17767302
pcu_sock_read() may not free the message buffer in case the recv
returned errno EAGAIN. This is already fixed in osmo-bts, lets fix it in
osmo-bsc as well.
Related: OS#5198
Change-Id: I49eda447fc1912c1f7f25ba07331cb84decf4548
There seems to be no way for this function to be called with NULL parameter despite unreproducible crash observed in the
past. Let's add assert to show this explicitly.
Fixes: OS#5551
Change-Id: I235bdd42ea82e7b5a1a40f437ca34c49ad239c48
This way it is a lot easier to find out how and when is an lchan
initialized, simply by looking at the lchan.h header, then seeing the
init function and grepping for it.
Change-Id: I043d1c2ee75d4d2a8b323b7960ee490e567f3865
It is really difficult right now to find out where all the different
stuff relative to operation and lifecycle of an lchan is. Let's move
everything to its own file to have all the related defines and logic
together.
Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
This API has been available since 1.0.0, and we actually require
libosmocore >= 1.7.0 nowadays, so it's totally fine using the
libosmocore API and drops the local duplicate.
Change-Id: I95c59b31cf1b08e1d513b589ef386d2dd55f09a2
The OM2000 model does not have a separate bb_transc MO, however for
compatibilty reasons we have a virtual MO that just mirrors the state of
the TRX mo. We should mark it as [Virtual] in show trx to reflect this
to the user.
Change-Id: I0f5501f6fbc7ce6d5457676b16c7f93f70db5763
Related: OS#5101
In OM2000 a separate bb_trxc MO does not exist to archive better
compatibilty towards classic ABIS and its MOs. Let's mirror the nmstate of
the BB_TRANSC MO to the RCARRIER MO in order to make it look like if it
were present.
Change-Id: I4611d8af16a30725308bd527098b12a356bfde9f
Related: OS#5634
the function om2k_trx_s_done_onenter() updates the administrative state
of the TRX oml MO but it does not notify the update to other entities
using S_NM_STATECHG
Change-Id: Iabf9f3a1a345c5d53d9a4d02fa2d6d13ddfd86ae
Related: OS#5634
Thanks to manawyrm for pointing out that the comments of the file
actually contained the numeric codes for the CBCH variants, but the
cases in the switch statements were missing.
Change-Id: Id5b4da6838f9a34db39fff5c23ad18822cd3347b
The function update_op_state() updates the OML MO, but it does not
notify the update to other entities using S_NM_STATECHG
Change-Id: Id19c6beb2bc79c4db0ec07ef593aacb57fff8b75
Related: OS#5634
The switch-case in update_op_state() and update_mo_state() can be split
off into functions. This makes to code better readable.
Change-Id: I41f0d9d0d498f6f698c2c959baac50424f5ac317
Related: OS#5634
The normal abis nm FSMs are sending S_NM_RUNNING_CHG signals that
include an object class to notify other entities about state changes.
This also includes paging.c, which only starts paging services when it
sees NM_OC_RADIO_CARRIER becoming enabled.
Change-Id: I305df5b2f962473e33e32484c42a79ff96e53e1a
Fixes: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
Related: OS#5634
In cases where the MGCP client endpoint FSM is terminating early the bsc
sbscr conn FSM receives the signal GSCON_EV_FORGET_MGW_ENDPOINT, which
then calls gscon_forget_mgw_endpoint(). However, this only nulls the
conn->user_plane->mgw_endpoint_ci_msc struct pointer, not the others.
This causes the assignment FSM to access
conn->assignment.created_ci_for_msc whle trying to initiate a DLCX. We
must make sure that when the MGCP client endpoint FSM dies, that all
other CI pointers that reference the same CI are also set to NULL.
Change-Id: Ia857e3af6c17282b7e8178b6d249eb0f99ed98e3
Related: OS#5572
As described in 3GPP TS 48.049:
7.8.2: "The RESTART message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
7.9.2: "The FAILURE message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
Related: SYS#5910
Change-Id: I6668b55868cf534a3b59da5e11542abb8131d604
Let's use CGI instead of LAC+CI, which contains only a subset of the
information.
Furthermore, It was noted that some third party (non-osmocom, non
open source) CBCs don't support/like receiving LAC+CI,
and expect to receive CGI instead.
Related: SYS#5910
Change-Id: I33a6216f89496484cbb3921609fcd3ab90761c69
When trying to build osmo-bsc using clang 14, I am getting this error:
make[3]: Entering directory 'src/osmo-bsc'
CCLD osmo-bsc
/usr/bin/ld: ./.libs/libbsc.a(handover_decision_2.o): undefined reference to symbol 'pow@@GLIBC_2.29'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [Makefile:656: osmo-bsc] Error 1
We need to link with the math library to resolve this.
Change-Id: I4137cad07a3343882ca77d5ebd5137083941dc11
GCC 12.1.0 emits -Wmaybe-uninitialized when building with '-O2'.
In function 'populate_ts_list',
inlined from 'lchan_avail_by_type' at src/osmo-bsc/lchan_select.c:356:2:
src/osmo-bsc/lchan_select.c:248:12: warning: 'chan_alloc_reverse' may be used
uninitialized [-Wmaybe-uninitialized]
248 | if (chan_alloc_reverse) {
| ^
src/osmo-bsc/lchan_select.c: In function 'lchan_avail_by_type':
src/osmo-bsc/lchan_select.c:326:14: note: 'chan_alloc_reverse' was declared here
326 | bool chan_alloc_reverse;
| ^~~~~~~~~~~~~~~~~~
This could only happen if in 'enum lchan_select_reason' we had items
that are not handled in lchan_avail_by_type(), but this is not the
case. Make GCC happy by initializing chan_alloc_reverse to false.
Change-Id: I3956621a6ec14ca5ff0ba0b11d2c956e2538efd8
This change implements an additional channel allocation mode, which
can be employed during a TCH channel allocation for assignment.
Selection between ascending and descending order is performed
depending on pre-configured parameters:
* Uplink RxLev threshold and number of samples for averaging,
* C0 (BCCH carrier) channel load threshold.
This is useful in setups where Tx power of the RF carriers cannot be
adjusted +dynamically at run-time and thus BS Power Control cannot
be performed. In such setups the BCCH carrier is transmitting at
relatively higher power than the other RF carriers. The key idea
is to allocate channels in a smarter way, so that UEs with poor signal
would get channels on carriers with high Tx power, while UEs with good
signal could use carriers with lower Tx power.
Change-Id: I1b7a0d706976b73cc5c30a8714b830811addfe8d
Related: osmo-ttcn3-hacks.git Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
A follow-up patch implements a special channel allocation mode, which is
only working for assignment (basically TCH selection for a voice call).
This mode cannot be employed for initial CHANNEL REQUEST or handover due
to the absence of an already established lchan.
Adding this mode to the existing VTY command syntax would be confusing:
channel allocator (ascending|desscending|dynamic)
^^^^^^^
so this patch extends the VTY syntax in a way that it becomes possible
to configure different channel allocator modes for different cases:
OsmoBSC(config-net-bts)# channel allocator mode ?
set-all Set a single mode for all variants
chan-req Channel allocation for CHANNEL REQUEST (RACH)
assignment Channel allocation for assignment
handover Channel allocation for handover
The old command syntax, which is basically 'set-all', is kept for
backwards compatibility, but marked as deprecated.
Change-Id: I3ae73b36ee9433cc768376b56f0765e5f416162f
Related: SYS#5460
The lchan_avail_by_type() attempts to find an unused lchan for the
given GSM_LCHAN_* value: TCH/F, TCH/H, or SDCCH. This is achieved
by looking up timeslots with compatible GSM_PCHAN_* values.
For instance, finding an unused SDCCH lchan may involve:
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4,
* attempt to find a timeslot with pchan=GSM_PCHAN_CCCH_SDCCH4_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C,
* attempt to find a timeslot with pchan=GSM_PCHAN_SDCCH8_SACCH8C_CBCH,
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (switched),
* attempt to find a timeslot with pchan=GSM_PCHAN_OSMO_DYN (not switched).
Each attempt involves iterating over all timeslots of each TRX,
either in ascending or in descending order (see _lc_dyn_find_bts()
and _lc_find_trx()).
This patch simplifies the lookup logic by preparing a monolithic
array of timeslot pointers once, and then using that array for
each GSM_PCHAN_* lookup attempt. This change is required for the
upcoming dynamic channel allocation mode, which is fa more complex
than the existing ascending/descending ones.
A side effect of this change is that the interference aware mode
of allocation is not limited by the scope of a single TRX anymore.
Interference levels are now compared within the scope of the whole
BTS, so that lchans on the other TRXes may be picked if they are
better according to the interference reports from the BTS.
Change-Id: I7ccc56856bfd40fd7c63b7437736de60c2b516ff
Related: SYS#5460
Let's decrease the logging since it's fine simply discarding the message
if the link is down. This way all code sending messages doesn't need to
care about the link state.
Change-Id: I64356ec6a7b3a4e11a0e66b17efab2788b1ca5cc
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Idb0e6565e362ce383c833d6bfec4fb39d2985a6b
Fixes: CID#272982, CID#272944
Found by clang:
warning: implicit conversion from enumeration type
'enum lchan_activate_for' to different enumeration type
'enum assign_for' [-Wenum-conversion]
This is indeed a bug, because both enum items have different values:
* ACTIVATE_FOR_VTY (from enum lchan_activate_for) is 4,
* ASSIGN_FOR_VTY (from enum assign_for) is 3.
Change-Id: I44544d4577833e0aed62b07d0c7c1c2821b05dd4
Fault Reports are commonly oberved with a TLV id 0xd2
as are reports with up to 20 TLVs.
Let's not have these cause logging at level ERROR.
Closes: OS#5593
Change-Id: Ibe0b38835362c59d1576a206b2f64cea4427295f
This way the CBSP peers knows the state of specific cells and can avoid
sending messages to unoperative ones, etc.
Related: SYS#5910
Change-Id: I94f0a1ac3c59cffe5af57f972d5d96fc92281d34
When calculating average lchan duration based on the new stats for
BTS_CTR_CHAN_{TCH,SDCCH}_ACTIVE_MILLISECONDS_TOTAL there are
discrepancies which emerge. Specificially in bandwidth-constrained
environments, there are still-unknown failure states which can
occur that cause the TCH or SDCCH activity count to increment but
zero milliseconds of activity on the lchan to accumulate. This
portrays a failure as a success.
These new fully-established stats are intended to provide a more
accurate denominator when calculating average lchan duration as
they are incremented in proximity to the duration timestamp
initialization.
Change-Id: I417940ad9479719f5324fb12d45883cd3cb2c578
This allows running CBCH/ETWS related procedures only when the CBCH
towards MS under that cell is operative.
This also allows providing awarness of per-cell status to the CBSP peer
as required per specs.
Related: SYS#5910
Change-Id: Ia93919be94132fc010acb5bbfef0a6fd51c42981
For statistical clarity and site tuning, it is sometimes
desirable to completely disable the use of TCH for signaling.
In the existing version of this VTY command, there is no way to
accomplish this. We can only restrict TCH for signaling non-voice
related actions.
This patch deprecates 'allow-tch-for-signalling (0|1)' and
adds 'tch-signalling-policy (never|emergency|voice|always)' to
provide more options.
Change-Id: I4459941ddad4e4a3bec8409b180d9a23a735e640
This way we separate all the VTY boilerplate from the actual logic, as
we usually do in all other subsystems.
Change-Id: Ifc7d1693d745dd2a3c31e3ee9610d8c634b50812
Drop "to this MSC" from the NRI_STR, as it is not only used for MSC
specific configuration, but also in cfg_net_nri_* which affect all MSCs.
Drop "for this MSC" from the description of cfg_net_nri_null_del, it
affects all MSCs (unlike cfg_msc_nri_del).
Change-Id: Ic8888775a965b6d607af51b9359bd8ffc2834e16
The all_allocated_update_bsc() does inefficient iterating to count
active/inactive lchans, which scales badly for high numbers of TRX
managed by osmo-bsc.
We need to update the all_allocated flags immediately (periodic counting
alone would suffer from undersampling), so, until now, we are calling
this inefficient function every time a channel state changes.
Instead of iterating all channels for any chan state changes anywhere,
keep global state of the current channel counts, and on channel state
change only update those ts, trx, bts counts that actually change.
A desirable side effect: for connection stats and handover decision 2,
we can now also use the globally updated channel counts and save a bunch
of inefficient iterations.
To get accurate channel counts at all times, spread around some
chan_counts_ts_update() calls in pivotal places. It re-counts the given
timeslot and cascades counter changes, iff required.
Just in case I missed some channel accounting, still run an inefficient
iterating count regularly that detects errors, logs them and fixes them.
No real harm done if such error appears. None show in ttcn3 BSC_Tests.
It is fine to do the inefficient iteration once per second; channel
state changes can realistically happen hundreds of times per second.
Related: SYS#5976
Change-Id: I580bfae329aac8d4552723164741536af6512011
Reduce some code dup in all_allocated accounting and cosmetically
prepare for upcoming performance fix.
Have a struct all_allocated, allow easy re-use of function
all_allocated_update().
Rename function to all_allocated_update_bsc(). Upcoming patch will also
add all_allocated_update_bts().
Related: SYS#5976
Change-Id: Id7a82c65d56a87818fc35bbeedf67e2af2f89f11
ts_is_usable() returns the current state; logging is the job of calling
functions. An upcoming patch adds some calls to ts_is_usable(), this
avoids the log flaring up with useless messages.
Related: SYS#5976
Change-Id: I0635c47609fd7c7d0195b6658b7da231d6527b4b
It was described in [1] that the NM FSM failed to trigger the
S_NM_RUNNNG_CHG signal when locking/unlocking the TRX.
That's because current osmo-bts doesn't fully conform to TS 52.021 and
it doesn't go back to Op=Disabled Avail=Dependency when becoming
Admin=Locked. It's true though that TS 52.021 sec 5.3.1 is not really
helpful since it doesn't explicitly state that specific object should go
into Disabled Dependency, despite saying it for most of the other ones.
Hence, let's account for both possibilities at the BSC side.
[1] https://gerrit.osmocom.org/c/osmo-bsc/+/28205
Related: OS#5576
Change-Id: Ifbdc066fd88bdbf826800d14524e74416815b625
Since b7ef6884f9, the state is updated
before triggering the signal S_NM_STATECHG, so the warning does no
longer hold true.
Change-Id: I7b7dd30b4fcdc92febca42e3e6a75e6f98e184ff
Add missing conn->assignment.created_ci_for_msc to
gscon_forget_mgw_endpoint_ci().
Before this patch, when assignment.created_ci_for_msc lingers after a
DLCX, it can cause a use-after-free on assignment_reset(). Possible
scenario is rx BSSMAP Clear Cmd during ongoing Assignment.
In assignment_reset(), locally cache the ci pointer, because
gscon_forget_mgw_endpoint_ci() now NULLs created_ci_for_msc.
Related: OS#5572
Change-Id: If89610020f47fd6517081dd11b83911b043bd0f1
VAMOS lchans are behind the primary ones in the ts->lchan[] array.
For example, for TCH/F, there is a primary ts->lchan[0] and a VAMOS
ts->lchan[1]. We should print 'ss 0' for both of them.
Change-Id: I8e7a5a2ecc9b9a33e3ddb76cb1bc04d7802fd320
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
As per TS 48.049 Table 8.1.3.1.1 the WRITE-REPLACE message always
has a Warning Security Information IE if it relates to ETWS. This
is also implemented in the libosmocore CBSP parser.
As the previous Change Id369bb3676ba279bafc234378fbe21dbc7b0614b has
pointed out, the CBSP parser structure doesn't even permit any way
of handing a decoded message to us without the warning_sec_info
static struct member.
So as a result, there's also no need to dynamically allocate
bts_etws_state.input.sec_info via talloc. We can have it in-line
as a static struct member and reduce code complexity and runtime
memory allocations.
Change-Id: Ib1b8e4af37b1f9f9398b81dad29942e82218c70b
The proper way to fix this is having a use count on the SCCP conn, one
each for a busy lchan and a busy Location Request. That would require a
bunch more work and testing.
This patch is the least-effort way to avoid the following scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
Perfectly fine Location Request gets canceled by Clear Request;
The information was there, but we did not forward the location;
No help at emergency because of my code.
Allow Location Request to complete for these cases:
- rx RLL REL IND (or any other reason for gscon_lchan_releasing())
- rx RSL CONN FAIL
Related: SYS#5912
Related: Idea690a4aa4aecbe4642a16e96d086cc0538564a (osmo-ttcn3-hacks)
Change-Id: Ib44dd05b0adee84234f671313b156ff6625357cc
ACC used to be stared/stopped based on operational/administrative state
changes. The new S_NM_RUNNING_CHG triggers a single boolean based on the
same logic, so we can now simplify the mechanism.
Change-Id: I2e09bcb18a6c3bb2e88bba98579fb4854a6b0699
This way we avoid triggering timers and doing extra poll loops for each
BTS which is configured but not up. It also has the effect of removing
logging about estimating paging buffers for BTS which are down, which
can be confusing.
Furthermore, since work is delayed until the TRX and cell in general is
configured, the first estimation is properly done now since the correct
configuration is in place at that time.
Related: SYS#5922
Change-Id: I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44
This allows different parts of the code to hook to some signals which
allow start/stopping processes based, for instance, on whether C0 is
available or not.
This can be later used by paging or CBSP code. Also ACC code can be
ported to this new system (acc_ramp_nm_sig_cb()).
Same signal can be used for other NM objects, but is left unimplemented
until there's use for them.
Change-Id: I206d4c7863a77fbab6a600126742a6a6b8fc3614
This way code triggered through signal has an updated view of the object
tree when running generic code which queries the current state of
objects.
This way for instance one can use APIs like trx_is_usable() or alike.
Change-Id: Ib46234e3f3e446e866d27b0dfee65edf4af4d2ba
Found by GCC 12.1.0:
smscb.c: In function 'etws_primary_to_bts':
smscb.c:537:13: warning: the comparison will always evaluate as 'true'
for the address of 'warning_sec_info'
will never be NULL [-Waddress]
537 | if (wrepl->u.emergency.warning_sec_info) {
| ^~~~~
In file included from smscb.c:31:
/usr/local/include/osmocom/gsm/cbsp.h:99:33: note: 'warning_sec_info' declared here
99 | uint8_t warning_sec_info[50];
| ^~~~~~~~~~~~~~~~
Indeed, address of &warning_sec_info[0] is always not NULL.
Change-Id: Id369bb3676ba279bafc234378fbe21dbc7b0614b
Don't wait until RSL link goes up to check the reported features against
the config. Do it in the OML bring up right after the features are
reported.
Related: SYS#5922, OS#5538
Change-Id: I6b1b4ef3e163528ed186050d848ec089a4315a7c
Especially during emergencies / natural disasters, it is particularly
likely that networks become unreliable and BTSs disconnect and
reconnect. If upon reconnect there still is an active ETWS/PWS
emergency message active for this BTS, send it to the BTS to ensure
it re-starts broadcasting that message until disabled.
Change-Id: I175c33297c08e65bdbf38447e697e37f8a64d527
This reverts commit 5e2ac29703.
This patch was found to be a troublemaker regarding osmo-bsc
performance, since it's scheduling one timer every 100ms for each
channel. On a BSC with dozens of BTS, each with several TRX, this ends
up in a huge amount of timers scheduled in a tight timeframe, which ends
up in osmo-bsc spending CPU time getting in and out of the poll() main
loop.
Related: SYS#5922
Change-Id: Ibd5123e7f04ae8f4eb8f08b63525527f526f0b2c
This allows external monitoring to see where the T3113 timer has been
adjusted to, in case it is set dynamically.
Change-Id: I533f2ca3c8e66c143154cbf03b827c9cbbacccdf
Reaching this point will only make system load (CPU, mem) grow, making
it hard for the process to keep up with work to do, with no benefit
since the requests will anyway be scheduled too late.
Related: SYS#5922
Change-Id: I6523c6816a4d16b71084d004e979be40cf0aeeb0
In lchan_fsm_cleanup(), ensure that the time_cc timer is actually inactive
before deallocating. Do so via lchan_reset(), to also make sure the
timer is stopped in all other situations where the lchan is deactivated.
This fixes an infinite-loop deadlock as described in OS#5554:
- run BSC_Tests.TC_chan_act_ack_est_ind_noreply
- restart the BTS process after the test is done
- osmo-bsc enters infinite loop in osmo_timer_del()
The reason is that lchan_fsm_cleanup() fails to stop a running active_cc
timer upon lchan deallocation. TC_chan_act_ack_est_ind_noreply
incidentally terminates OML while the timer is still active.
Related: OS#5554
Change-Id: I901bb86a78d7d021c8efe751fd9d93e5956ac0e0
We have seen an increased CPU load in osmo-bsc recently since the paging
improvements where merged, centered round poll() calls.
It is expected most of them will be fixed with previous patch. In any
case, let's avoid unnecessary poll() calls being called for no reason.
Related: OS#5922
Change-Id: Ie767bdc8d4353aafe375a424e02d698ef7fd3dea
We want to recalculate the timer based on last time the work_timer was
triggered (that is, the time when the worker re-armed the pag req to
retransmit). We don't want to recalculate based on the last time the pag
ret tro retransmit was scheduled.
In loaded paging queue, there's lots of retrans (let's say 200) and it
may take more than 500ms to actually retransmit them. That means in most
cases we could end up in a situation where only pag req to retrans where
in the queue, hitting this recalculate path. Since the 500ms were for
sure elapsed, that would most probably schedule the work_timer at {0,0}
for each new paging request that arrived. As a result, the worker would
be scheduled lots of times per second (once for each new req arriving)
and only submitting 1 pag req (the new one) plus potentially 1 or
serveral pag req to retransmit.
In summary, there was not throthling applied in the scenario where only
pag req to retransmit where in the queue and new pag reqs kept arriving.
This incurrs into augmented paging throughput and also augmented
frequency of polls().
Related: OS#5922
Fixes: 4821c9f4df
Change-Id: I7ce6f436286b50dc31331d218ff256cf7be3f619
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
One callback function was being registered for each BTS.
That means, when a C0 RCARRIER of one specific BTS changed NM state,
the outcome on whether to trigger/abort ramping would end up being
applied to all BTS.
Change-Id: I56c4dd1809fdcf8441a69bf77ad173e1ccc8eea7
This makes sure code accessing those fields is not changing its values,
since it would make no sense to change those. Follow up commit will make
convert those pointers to be full structs instead, as there's no need to
have pointers there.
Change-Id: I9979e62eac861e25bbe2161ab187ddb2b40fd097
Having 2 signals makes all code handling them more complex, specially
because S_NM_STATE_CHG_OPER could actually provide any change in
admin/oper/availability.
Both signals already provided the same kind of data (the whole
admin/oper/avail state change), so let's simply merge the signals
themselves. Current code really doesn't act differently for those 2
signals anyway.
Change-Id: Ia86d20a42b859063d0327b940ba528ec1438b04a
This code is not used currently. Furthemore, it makes little sense to
transmit an OPSTART if the BTS already told us it is enabled (because
OPSTART is what moves the BTS into operational enabled state).
Change-Id: I2c65e0803fbde7de9497089b562275baad58936a
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:
1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output
2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.
Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347
So far we only calculated the expiration time based on the amount of
requests of the same paging group in the BSC queue.
However, also extra time has to be taken into account regarding requests
of other paging groups. This is important because requests of all paging
groups are mixed in the BSC queue, meaning having a lot of requests from
other groups before a certain req will anyway delay transmit of that
req to some extend.
Related: OS#5537
Change-Id: Ib55f947c5d3490b27e1d08d39392992919512f9a
This was so far workarounded in tests by manually freeing the fields.
However, in follow-up patch the paging queue will also be properly
freed, so free of the counters needs to be previously fixed too so that
counters are freed at the right point of time.
Otherwise, during paging queue flush, counters are used and would crash
because they were freed before the BTS object in each test's bts_del().
Change-Id: Id213e21cf9bfc5439021e459c22ba4704d8cae2b
Use the same one as used to decode the message in osmo-bts.
This patch doesn't cause a change in logic since both headers are binary
identical.
Change-Id: Ideb863fdaedf77caac1a320de6696ba4f507a398
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
If the queue is only holding requests in retransmition state, when we
add a new one, we have to re-calculate the work timer to a lower value
instead of letting it wait for the first retransmit to be ready.
Change-Id: Ibd4f8921c92f7481f0b9943041c141640ab812c8
There's no need to keep the timer running, since anyway upon next
trigger it will simply early exit in paging_handle_pending_requests()
becuase there's no more work to do.
Change-Id: I096ab7231f52c741c5fded37acd5b309e1de06e3
Before this patch, on each BTS a 500ms timer was used to schedule some
work, sending up to 20 paging requests verytime.
This means, however, for an initial paging request it may take up to
500ms delay to be scheduled to the BTS, which is huge.
While we still want to maintain this 500ms interval for retransmits, it
doesn't make sense to wait that much for other cases. It's far better
sending less requests (10 instead of 20) every half time (250ms instead
of 500ms), since it will spread the load and paging more over time,
allowing for other work to be done in the middle.
Change-Id: I7a1297452cc4734b6ee8c38fb94cf32f38d57c3d
PAging happens over C0 RSL link, not over OML, so let's actually
validate that the C0 RSL link is up before paging instead of the OML
one.
Change-Id: I11e5bb6f952534763935aa01470e514d4af247ed
Decouple credit_timer from event "available_slots became 0".
Let's actually relate credit_timer to the fact of not receiving CCCH
Load Indication: If no CCCH Load Indication is received (cch_load_ind_period * 2),
then assume we are below CCH Load Indication threshold (10% load) and
start estimating the available_slots in a cch_load_ind_period*2 time
frame.
Moreover, in paging_schedule_if_needed(), there's no use in delaying
start of processing work if the work_timer is not already doing work.
Related: OS#5537
Change-Id: I6a0da03c408270044079e81d431f6641527c00cd
From 3GPP TS 48.018:
If only the New Serial Number IE, and not the Old Serial Number IE, is
included in the WRITE-REPLACE message,then the BSC shall interpret the
message as a write request, i.e. a broadcast request of a new emergency
message without replacing an ongoing emergency message broadcast.
Only one emergency message at the time can be broadcasted in a cell. If
a write request is received for a cell where an emergency message
broadcast is currently ongoing, the write request is considered as
failed.
Change-Id: I376c9e796f3a2d26b22d0451f15ef1debbd7f656
Closes: OS#5539
Related: SYS#5906
So far, we only implemented KILL for CBS, but not for Emergency
broadcasts. This patch adds KILL support for Emergency, by which
a CBC can terminate broadcast of a previously-started Emergency
message before its scheduled period ends.
Change-Id: Ie91939b93de6847eeb5d00c97a137c43721c2711
Closes: OS#5540
Related: SYS#5906
ETWS is sent over both dedicated channels and broadcast channels.
Some BTS models may not support the latter, but it is still useful
to start the related timer to ensure bts->etws.active gets set to
false after the emergency period has concluded.
Change-Id: I448be9fd75b87c1f7333a5bfa4f6ba238569fdc3
Only if we store data like the CBSP message_id and serial_number
we are able to later (in a subsequent patch) match a CBSP KILL
for ETWS/PWS and stop emergency broadcast.
Change-Id: Ide74638880d7e3c6a7c774bf6320d3dce4b11c74
Related: OS#5540
TS 48.049 states the following rules for the KILL COMPLETE / FAILURE
messages:
The Number of Broadcasts Completed List IE, if present, contains for
each cell the total number of broadcasts of the killed CBS message.
The Cell List IE, if present, contains the cells in which the emergency
message is successfully terminated.
As any message can only be either emergency or CBS, this means that
we can (at maximum) have only one of those two IEs in the message.
As there is no explicit indication in the KILL whether it relates
to CBS or Emergency, we use the "Channel Indicator" IE, which is
specified as "only included if the message refers to a CBS message".
Related: SYS#5906
Closes: OS#5541
Change-Id: I9a43d386da01f085663d231a555b8b5acc99faca
With previous patch Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, the
features get copied from the BTS model to the BTS. For rbs2000, bs11 and
nokia_site, an empty feature set was copied because the features weren't
set at this point. Fix this by moving the set_feature calls to _init().
Notably the set_feature calls had been moved for osmo-bts and nanobts
from _start to _init already in 2013 in the patch e84dd98d
("sysmobts: Avoid a crash when trying to look-up a BTS").
Fixes: 2d818b9f ("Always use reported features if available")
Related: SYS#5922, OS#5538
Change-Id: I43389ae48d5e0f01381602751f6bad902011b158
When building with CFLAGS="-flto -Wall", I get the following:
meas_pcap2db.c: In function ‘pcap_cb’:
meas_pcap2db.c:64:27: warning: pointer targets in initialization of
‘const char *’ from ‘const u_char *’
{aka ‘const unsigned char *’} differ
in signedness [-Wpointer-sign]
64 | const char *cur = bytes;
Change-Id: I84d8e6f290bda0f03476f182f292ecc7a9e520f2
When building with CFLAGS="-flto -Wall", I get the following:
meas_db.c: In function ‘_insert_ud’:
meas_db.c:62:23: warning: unused variable ‘rowid’ [-Wunused-variable]
62 | unsigned long rowid;
meas_db.c: In function ‘meas_db_insert’:
meas_db.c:89:13: warning: unused variable ‘rc’ [-Wunused-variable]
89 | int rc;
meas_db.c: In function ‘check_create_tbl’:
meas_db.c:260:16: warning: unused variable ‘rc’ [-Wunused-variable]
260 | int i, rc;
Change-Id: Id12958f67a47b6b3ebece7252e4f7c0835d4bb96
Instead of sometimes checking against hardcoded BTS model features, and
sometimes against features reported at runtime (which only some BTS
models do):
* copy the hardcoded BTS model features to BTS features initially
* do all checks against BTS features
Related: SYS#5922, OS#5538
Change-Id: Idf2d933aa8b03b1f708e56a08707fe6c620a97aa
Let all changes of the bts model go through this function, so we can in
a future patch copy over the bts model's features to the bts.
Related: SYS#5922, OS#5538
Change-Id: I8475c8c20eb72411e8ca820181d1c8603c22a56d
Just log all reported features, instead of comparing them against an
expected set of features and logging mismatches. The point of reporting
features from the BTS at runtime is that the BSC can support various BTS
versions with various feature sets.
Related: SYS#5922, OS#5538
Change-Id: Ibd79bc7ef802d8e95e05d746df182ff974b78e29
After the lchan release, the gscon would go into the Clear dance with an
arbitrary cause value. Instead, explicitly ask for a Clear upon
pre-emption, with the proper cause value.
Related: OS#5535
Change-Id: I20108f7b4769400b89b7b0d65c8dab883bf87c46
So far the we indicated pre-emption in the release cause of denying an
emergency setup, instead indicate protocol error.
When emergency calls are disallowed, it is not pre-emption (making room
for an emergency call) but a protocol error (MS asks for emergency call
when the network does not allow it).
Related: OS#5534
Change-Id: Ia195621165cb7bbe33e6c2e915abc42ab16a2a4f
Its name is totally misleading, since they seem to be related to
GetAttributes messages rather than SetAttributes.
Change-Id: I306cb407dbd9b98e301b5d93046bdadcb466b82b
Currently, the Tx paging_req queue at the BSC always has new paging
requests adding at the end (as long as the subscriber is not already in
the queue).
That means, if the queue is full of retransmitions, it will take a long
time until the first paging_req is sent towards that subscriber.
The rationale here is that it makes sense to attempt the first paging
ASAP, and give lower prio to paging_req retransmitions, since it may
well be that those other subsribers are not available/reachable and
won't answer.
Related: SYS#5922
Change-Id: I1ae6d97152c458247bc538233b97c2d245196359
Having one paging request being sent every PAGING_TIMER (500msec) is too
slow in case BSC is serving lots of subscribers on a BTS. Hence, we want
to send many paging requests at once while still trying not to fill the
BTS buffer.
Morever, we don't want to send tons of paging requests at once, hence we
limit the amount of paging requests sent in one timer iteration
(MAX_PAGE_REQ_PER_ITER) in order to avoid the BSC doing lots of work
there at once, keeping it busy from processing other tasks.
Related: SYS#5922
Change-Id: I609fa67834b426456f48f6fb2acb601c5905f178
The variables are unsigned, so -1 gets actually translated to UNIT16_MAX
when the value is casted to uint16_t. Let's do that explicitly so that
readers don't think those are signed variables.
Change-Id: I02ad80e5d10f1a47cdf712f7f7c576a2e20fe607
If an lchan needs to be released to make room for an emergency call,
send the proper release cause ("pre-emption").
Related: OS#5534
Change-Id: I0423621d15ace11a53ae1653e5e7f5cb93605edb
Order the features and add a comment that reminds of updating OsmoBTS
to actually report the new features that are assumed to be supported
here.
Related: SYS#5922, OS#5538
Change-Id: I6f041648990db4ae479538cf3970c826bc6703ed
pcu_sock.c: In function ‘pcu_tx_info_ind’:
pcu_sock.c:197:2: error: #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
197 | #warning "isn't dl_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
pcu_sock.c:199:2: error: #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs" [-Werror=cpp]
199 | #warning "isn't ul_tbf_ext wrong?: * 10 and no ntohs"
| ^~~~~~~
they made it here from osmo-bts.git
(b4999b60d4 states that the PCUIF support
was copied from there). The gitlog shows that these warnings were added
in 744f745d7a508605254afa8f78412ad410d153b0 by jolly (in 2012!)
together with the PCUIF support, and before
c1368d4ebe49f8e01f1f5fff3bc3583cb5960c1d these warnings were in German:
"ist dl_tbf_ext nicht falsch?"
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: I9ef7e18f56aa86b48f0ffeec58406260736170f3
From Vadim in https://gerrit.osmocom.org/c/osmo-bsc/+/27818
By checking !(link_id & 0xc0) we actually make sure that this is not
SACCH. So the comment "but not if the link_id contains a TCH flag" is
wrong, there is simply no such thing like "a TCH flag".
Change-Id: I8f0f6d7bf952426fd2f27802f1499d6ee8981982
If the BTS tells us SAPI=0 is gone, there is no point in trying to keep
the lchan around for SAPI=3, as it is not possible to operate GSM with
SAPI=0 gone.
This occurred with RBS6000, which don't seem to send RLL REL IND for
SAPI3 after doing so for SAPI0. However, rather than an
ericsson-specific hack, let's make this the general rule: If SAPI=0
is gone, don't stop the lchan from being released.
Change-Id: Ia9caa5b0a5efdc459d94621367376927959a6e65
Related: OS#5530
If we receive something unexpected, log it (and free the msgb!)
Change-Id: I43fab6a3a1c5e7a6545d6ef848636f5ba1be1576
Related: OS#5530 (only tangentially related)
The penalty timer low_rxqual_as() is only supposed to apply on an
intra-cell re-assignment. However, a segfault has been reported that
apparently applies it to inter-BSC handover.
Make sure that this timer applies only to re-assignment. In effect this
makes sure that the target bts is non-NULL and avoids the segfault.
Related: OS#5525
Change-Id: Ifdb9891fbe7e3f3423a96371def4fcbf2fc0bc0d
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. Since we alrady have code to encode it, let's
just always add it - it certainly won't hurt.
Change-Id: I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
Closes: SYS#5906
This is cosmetic change making the default multi-rate configuration
easier to read/understand and modify.
Change-Id: I3d03c2188d007a60a86961a346744400bc81d4e6
Related: SYS#5917, OS#4984
* Always say 'codec mode', not just 'codec'.
* Suggest proper modes in AMR_{TH,HY}_HELP_STR.
* Use 3GPP's definition of threshold and hysteresis.
* Clarify that threshold and hysteresis values are in 0.5 dB steps.
Change-Id: I996eae8aafeb2850e5e1a6f5a7764d745e1289b5
Related: SYS#5917, OS#4984
Now that we have separate header/code files for the power control,
let's move the related definitions there. This change makes the
code consistent with osmo-bts, where it's already done this way.
Change-Id: I1cb3f6bfba0306e8f371dcd5162d1813beb3a088
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: Ie3d4b481cbfacf27004787616e22b6f8a863b47b
When the assignment succeeds, the assignment_request has taken effect
and whatever it requested should now be in effect.
Hence copy the new RTP information from the assignment_request to the
conn's storage indicating what is currently used, always, not only when
lchan_changed == true. The RTP information may have changed also from a
Mode Modify where the lchan stays the same but changes its mode of use,
e.g. from signalling to voice.
When there is no RTP involved, this data is zero or empty, so there is
no harm in copying it, always.
Related: SYS#5916
Change-Id: I0788d1f013b8f820f559b6ed58a5f9bb8a02e0b4
When the assignment fails, we roll back the MSC side RTP endpoint at the
MGW that may have been created before the failure occured. On success,
we clear the mgcp_ci pointer so it is not rolled back.
Always clear this, not only when lchan_changed == true. That is because
a channel Mode Modify may also have added a voice stream that should
retain the newly created RTP endpoint at the MGW.
If no voice stream is involved, the pointer should already be NULL.
There is no reason to have a condition for clearing this pointer.
Just always clear it.
This fixes all voice calls that modify a TCH lchan from signalling-only
to voice mode. Before this patch, their MSC side RTP endpoint was DLCX'd
right on assignment success.
In particular, this fixes Emergency Calls (which usually get a TCH lchan
assigned right from the start, and hence do a Mode Modify to add voice).
Related: SYS#5916
Change-Id: I5ab10ee7fd9c5d7608e8a06893881d990943feed
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. TRX1/C1 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Change-Id: Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
When bad RxQual causes handover to a cell with weaker RxLev, then
handover oscillation *will* happen, as shown in test_rxqual.ho_vty.
Introduce a penalty timer for a cell where we had bad RxQual.
This delays handover back to the cell with stronger RxLev by the penalty
timeout; hopefully the interference is gone after the timeout.
Usually, we set new configuration elements so that osmo-bsc behaves the
same as before the config item was added. In this instance, this makes
no sense, because no-one ever wants handover oscillation from bad
RxQual, which is guaranteed to happen without the new penalty timer. Set
it to 60 seconds by default, same as other penalty timers.
Related: SYS#5911
Change-Id: I057b156604a104a26a7ce45d1c7adadbf452c932
This add support for handling inbound MESSAGE STATUS QUERY from the CBC,
and responding with MESSAGE STATUS QUERY COMPLETE or MESSAGE STATUS
QUERY FAILURE, as applicable.
Change-Id: I3b738dc29d0ead4f735abeeb6960d3675cb05ae2
Related: SYS#5909
I find it weird that we store the A5 algorithm ID in a format that
is used on the wire: N + 1 (valid for both A-bis and A interfaces).
What confused me even more is that in some functions we print it
as if it was in a normal, human-readable format. And this is
also why one can see weird constructions like:
if (lchan->encr.alg_id > ALG_A5_NR_TO_RSL(0)) { ... }
Let's ensure that our internal structures use the A5/N format:
alg_id=0: A5/0 (0x01 on the A-bis/A interface)
alg_id=1: A5/1 (0x02 on the A-bis/A interface)
alg_id=2: A5/2 (0x03 on the A-bis/A interface)
...
alg_id=7: A5/7 (0x08 on the A-bis/A interface)
so that we can print and compare the value of alg_id without using
additional arithmetics. Let's also rename 'alg_id' to 'alg_a5_n'
as it most clearly indicates which representation it is storing.
This is how the above code snippet would look like:
if (lchan->encr.alg_a5_n > 0) { ... }
Change-Id: Ieb50c9a352cfa5481aebac2379e0a461663543ec
When copying the CBS page content from CBSP to RSL data structures, we
use the User Information Length as length argument in the memcpy. The
logic for that is that only this part of the message contains valid
data.
However, as the user information length is not passed on via RSL or
transmitted over the air, the receiving MS will get a page with
zero-initialized padding, rather than whatever the originator of the
message has specified. As zero bytes in the 8bit domain might get
translated into @-characters in the 7bit domain, this creates problems.
So instead, let's always copy the entire page (82 bytes) to ensure
transparency when passing on information from CBSP to RSL.
Change-Id: Iffcf1f6a7d41a08a2feffc6f2ac5634d940b63aa
Closes: SYS#5904
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the abovementioned IEs are present
in the original message, they must be delivered to the SMLC too.
Change-Id: Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Depends: libosmocore.git I8775a93cf4089b1752d040e43d2cba6b8997f955
Related: SYS#5891
On receipt of the Perform Location Request message, the BSC needs
to forward it to the SMLC. If the LCS Client Type IE is present
in the original message, it must be delivered to the SMLC too.
Change-Id: Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
It's really confusing having a "default" struct whose inner values are
changing based on previous state. Furthermore, it's only used in
generate_si13() so there's no need to keep it outside the function.
Let's move it inside the function and rename it to avoid confusion.
Change-Id: I3ae4dd017dd4dad10c0365d21727666dd8e9fd41
It makes no sense to enable that field if the ext_info.egprs_supported
field marks EGPRS as disabled.
From TS 44.060 11.2.5a:
"""
This message may be sent by an EGPRS capable mobile station
*in a cell supporting EGPRS* and where the EGPRS_PACKET_CHANNEL_REQUEST
parameter indicates that this message shall be used.
"""
Related: SYS#5891
Change-Id: I5ac173116f8681d7340b75b2baff110158fab9fd
If "bts->gprs.mode" was changed dynamically at runtime (VTY or CTRL), it
could happen that the egprs_supported was kept as "1" if the dynamic
change was EGPRS->GPRS.
In summary, if EGPRS support was set, it couldn't be unset until BSC was
restarted.
Related: SYS#5894
Change-Id: Id2c2319044da474642c4cc710baa27cfee4fb592
Values in ext_info are modified in several places, so it's difficult
validating whether we deviate from default. Let's always send it so that
we always have a clear view on what the MS uses.
This fixes a bug where paging_coordination or ccn_active would not be
announced if GPRS was not enabled.
Related: SYS#5894
Change-Id: If96de3e0d77503cf6344dfbc611f9260ac3281aa
The value in bts->si_common.chan_desc may get out of sync with the
actual value in net->T_defs (e.g. after changing it via the VTY),
so we need to sync it in generate_si3().
Note that synchronizing the values in cfg_net_per_loc_upd_cmd is
a bad idea, because the value of T3212 may also be changed using
generic timer management commands.
Change-Id: Iee291623c2825505eeb5175adcedadfe35375b9e
Related: SYS#5888
This was overlooked during the code review. GCC does not complain
because internally both 'enum handover_scope' and 'bool' are
interpreted as 'int'. Found this while running my WIP testcase
TC_srvcc_eutran_to_geran_a5_3. This change makes it pass.
Change-Id: I807fd4a0e700e54c67ca3547d9c0c1b442dd1c54
Fixes: I4e5b1163a71443d706f14ce4bfd5c2294c320432
Related: SYS#5838
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
Change-Id: I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
When running a multi-trx setup, upon stopping osmo-bts one can see:
DCHAN ERROR lchan_fsm.c:80 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR
DCHAN ERROR lchan_fsm.c:144 lchan(0-1-7-TCH_F-0)[0x612000010120]{UNUSED}:
(type=NONE) lchan activation failed
(lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR)
These messages show up when the following conditions are met:
* BTS model speaks A-bis over IP (ip.access, e.g. nanoBTS), and
* BTS has more than one transceiver configured.
The problem is that unlike traditional E1 based BTS models, ip.access
ones have a single global A-bis/OML link for all transceivers. Thus
when it goes down, in inp_sig_cb() we need to notify all timeslots
*of all TRXes*, not just TRX0.
Change-Id: I3dc657ac5a2c5334747bd4f4db1a658acb323942
Fixes: OS#5479
Historically, we first only had
BSS_MAP_MSG_ASSIGMENT_RQST
^
with missing N. libosmocore has this renamed a long time ago and
provides a shim #define that makes the typo version still work.
Having the typo is bad for grepping, so rather use the non-typo name.
Also rename the constant for the ass req counter which so far has a
similar typo, and fix the same typo in the counter description.
The counter name exposed on CTRL luckily doesn't have this typo in it.
Change-Id: Ieaa4f4e6e6f7e1563b1bd15a83f0c1a9112d2312
The ho_fail() macro includes a newline, so the callers should not add
one. Fix these cases where the extra '\n' fragments the logged message.
Related: SYS#5839
Change-Id: Ifdbce98be70c1aa127ae008d7a77b9795fd250d3
So far we completely ignore the codec list from the MSC in Handover
Request messages. This leads to error messages in subsequent handovers
because there is no Codec List stored on the conn:
DHODEC ERROR handover_decision_2.c:390 [...] No Speech Codec List present, accepting all codecs
Besides the error log, in hodec2 we may subsequently take bogus or
unexpected codec decisions, ignoring the MSC's choice of codecs, or in
the worst case picking an unsupported codec.
This also has implications on what type of lchan we choose for handover
target in hodec2: say, if no half rate codec is supported as per the
MSC's request, we normally avoid handover to a TCH/H, etc.
Intra-BSC HO after an Inter-BSC incoming HO is the only case where this
problem occurs, in every other scenario there is an Assignment Request
from the MSC, from which we properly store the MSC's codec list.
3GPP TS 48.008 does indicate that on AoIP this codec list shall be
included. So reject HO Request with missing Codec List, as we already do
for Assignment Request on AoIP.
This makes TTCN3 BSC_Tests for inter-BSC incoming HO fail, because our
tests so far omit the Codec List (MSC Preferred) on AoIP. The related
fix of the tests is If06de9c9b43d79f749447a4e2a340176eef75c79.
Related: SYS#5839
Depends: If06de9c9b43d79f749447a4e2a340176eef75c79 (osmo-ttcn3-hacks)
Change-Id: I117cc29d6d11db77d160de654f43f5993db6ee21
"inter-BSC MT" was the terminology of an early development stage of
inter-BSC handover, code review requested "incoming" instead. This one
was missed when applying code review.
Same in a code comment.
Related: SYS#5864
Change-Id: I1ca810542e89980ffda11876fd30626467e452d1
Oliver Smith
Philipp Maier
Max
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Harald Welte
Keith Whyte