Project

General

Profile

Bug #4736

handover related rate counter increments are missing

Added by neels 8 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/29/2020
Due date:
% Done:

100%

Spec Reference:

Description

it seems that only {BSC,BTS}_CTR_HANDOVER_ATTEMPTED rate counters are ever incremented in the osmo-bsc.git source tree.
Add missing counter increments for handover, and add rate counter validation to the ttcn3-bsc-tests handover testing.

Associated revisions

Revision 5a7d0179 (diff)
Added by Neels Hofmeyr 8 months ago

ho counters: count invalid target cell as 'error', not 'no_channel'

Related: OS#4736
Change-Id: If6d6b7262536831ebb2b638efe521dd5a8153cdb

Revision c859ef64 (diff)
Added by Neels Hofmeyr 8 months ago

fix 'handover:*' counters: add missing / move increments

Move initial 'handover:attempted' counts from bsc_subscr_conn_fsm.c to
handover_fsm.c, where all the other counters are handled.

Add missing increments for the overall 'handover:*' counts.

Related: OS#4736
Change-Id: I783bdedafc0eb8f2df9ea100792846fecc7ccbf7

Revision 01c06a91 (diff)
Added by Neels Hofmeyr 7 months ago

fix 'handover:*' counters: remove bogus increments

To handle cases of unknown handover type (like failure to find the target
cell), return -1 as counter code; treat -1 as skipping in ho_count_bsc() and
ho_count_bts().

The handover:* counters indicate overall counts, without knowing whether inter-
or intra-BSC, or whether the target ARFCN even exists. So they need to be
counted separately, and must not serve as fallback category in
result_counter_bsc() and result_counter_bts().

Related: OS#4736
Change-Id: Ie311e599d7bd35d33cf471c6c63e649246e8396a

Revision e6142d0e (diff)
Added by Neels Hofmeyr 7 months ago

fix HO inter-BSC-IN target bts for counters

Related: OS#4736
Change-Id: Id38c69695c4ab93733571c0c288a2d5c10624ace

Revision dbe59f69 (diff)
Added by Neels Hofmeyr 7 months ago

add {BTS,BSC}_CTR_INTER_BSC_HO_OUT_FAILED for RR HO Failure

So far, during inter-BSC outgoing handover, when receiving an RR Handover
Failure from the MS, it would be counted as 'error'. Instead, add the 'failed'
counter like for all other HO types.

It may make sense to omit the 'failed' counter for inter-BSC incoming
handover, because then we won't receive an RR Handover Failure message. I
probably got those two mixed up during initial development.

Related: OS#4736
Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471

Revision 90f7c3c0 (diff)
Added by Neels Hofmeyr 7 months ago

bssap: do not send a Clear Request after a Clear Command

During handover cleanup due to a Clear Command from the MSC, do not send
another Clear Request to the MSC. Only send that when no Clear Command was
received yet.

Add a flag rx_clear_command per gscon instance, indicating whether a Clear
Command was received, and exit early in gscon_bssmap_clear() when true.

This is part of patches fixing the rate counters around handover, which uncover
some bugs:
- Another patch enables proper handover result handling when receiving a Clear
Command.
- After that, the handover_end() handling would always cause sending a Clear
Request, even if a Clear Command was already received.
- This patch removes the extraneous Clear Request, for this scenario and for
all other corner cases that might still exist.

Related: OS#4736
Change-Id: Iab82cac0a7ffa7d36338c8ff7c0618a813025f13

Revision cd219d88 (diff)
Added by Neels Hofmeyr 7 months ago

handover_fsm: signal Clear from gscon, for proper HO result counts

An inter-BSC-OUT handover ends with a Clear Command, which HO_OUT_ST_WAIT_CLEAR
waits for. Actually tell the handover_fsm.c about an incoming Clear Command, so
that the inter-BSC-OUT success can be counted.

Similarly, count failing handover results for an unexpected Clear Command from
the MSC.

Related: OS#4736
Change-Id: I0c489838a99f930e2104619ca745191d2a736f1b

Revision 4d266882 (diff)
Added by Neels Hofmeyr 7 months ago

handover: fix detection for ambiguous HO neighbor ident

Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the
test passes for the wrong reason. The ambiguous cell identification should be
the cause for the handover error, but the log shows that instead a handover is
attempted to BTS 3 which is not connected.

find_handover_target_cell() first tries to find a precise match of values, and
in a second pass applies wildcards like BSIC_ANY and
NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous
matches.

Use the same code for both passes, by encapsulating in a loop of two, which
first runs with exact_match == true and then false.

Proper detection of the ambiguous target cell identification in
TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count,
see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks).

Related: OS#4736
Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks)
Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1

History

#1 Updated by neels 8 months ago

grepping for counter names doesn't cover it, because during handover, the counter names to increment are heavily composed by preproc macros:

result_counter_##obj##_##name() functions are called by result_counter_bsc() and result_counter_bts().
Then in handover_end() we have these to call the rate_ctr_inc() with the resulting counter number:

ho_count_bsc(result_counter_bsc(ho->scope, result));
ho_count_bts(bts, result_counter_bts(ho->scope, result));

So there appear to actually not be any missing counter increments.
Nevertheless take the opportunity to add counter validation to the ttcn3-bsc-tests, and make sure that these macros aren't buggy.

#2 Updated by neels 8 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90

#3 Updated by neels 7 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

patches merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)