Cellular Network Infrastructure » Radio Access Network » OsmoBSC

I think I managed to fix the problem. TC_assignment_sign now passes nicely on my side.

Unfortunately the testcase also had some problems. The first issue was that there was no g_pars assigned. There was only a local variable pars which was not used. This is fixed with:

https://gerrit.osmocom.org/7836 BSC_Tests: Assign g_pars in TC_assignment_sign

Also there was a problem with the guard statements in the altstep as_modify(). I am not entirely sure if my fix is correct but it looks plausible for me. Please have a look at:

https://gerrit.osmocom.org/7837 BSC_Tests: handle mode modify also for signalling

The problem on the osmo-bsc side was that the assignment complete message could not be generated because the function send_ass_compl() had no way to distinguish between an ASSIGNMENT COMPLETE for a voice channel and an ASSIGNMENT COMPLETE for a signalling channel. This is now fixed. I also removed some dead code (which is debatable)

https://gerrit.osmocom.org/7838 gscon: fix assignment of signalling channels
https://gerrit.osmocom.org/7839 gscon: remove dead code

The TTCN3 tests are not tested with docker since the modifications are minor and no changes to config files were made. However, I still need to upgrade the XML that models the expected results but I do not know how exactly to mask out the the runtime. Probably we have a commandline switch for that, or a script?

All the important patches got merged. However, there was some misunderstanding about the effect that the ASSIGNMENT COMMAND should have on the BSC side. Since we are already have a signalling channel assigned when we send the ASSIGNMENT COMMAND, we do not expect any MODE MODIFY activity on RSL level. The next we need to investigate is why osmo-bsc is performs the mode modify request despite we are already on a signaling channel.

osmo-bsc now checks if the channel mode modify is really necessary. If the mode matches already the desired mode, the modification of the channel is skipped and the ASSIGNMENT COMPLETE is sent back to the MSC right away:

https://gerrit.osmocom.org/8019 bsc_api/GSCON: prevent unnecessary channel mode modifys

The TTCN3 test does not pass yet, this is due to problems in f_establish_fully_ret(). the FSM that is modeled into the altstep expects st.modify_done set to true in order to accept the ASSIGNMENT COMPLETE. Normally this flag is set in as_modify(), but as_modify() is designed to only work with voice calls. We must add an exception here for this particular case, but I am afraid to mess up other testcases with that.

The patch got merged, but the TTCN3 test still needs to get fixed.

When we set st.modify_done to true before entering the altstep we are able to accept an assignment complete without requiring to go through as_modify first. We may also think about altering the guard statement that guards the assignment complete.

The code checks if an assignment (RSL) is necessary or not. If the channel type is compatible with the requested service we may go through as_modify if the mode is different from the current channel mode. If the current channel mode is the same as the desired channel mode we expect an ASSIGNMENT COMPLETE on the A interface directly. as_modify is then omitted. I still wonder why as_modify only works on voice calls (?)

I think we need a check that can decide if a mode modify is necessary or not. I wonder if g_chan_nr or st can be used to determine the current channel mode.

dexter wrote:

The patch got merged, but the TTCN3 test still needs to get fixed.

it makes sense to always address both at the same time, while the problem is still fully in one's head.

When we set st.modify_done to true before entering the altstep we are able to accept an assignment complete without requiring to go through as_modify first. We may also think about altering the guard statement that guards the assignment complete.

I'm not sure i fully understand, but any patches against the ttcn3 bsc test are welcome.

The code checks if an assignment (RSL) is necessary or not. If the channel type is compatible with the requested service we may go through as_modify if the mode is different from the current channel mode. If the current channel mode is the same as the desired channel mode we expect an ASSIGNMENT COMPLETE on the A interface directly. as_modify is then omitted.

I still wonder why as_modify only works on voice calls (?)

why would you modify any signaling channel? The assumption here is that every channel from the beginning on is first in signalling mode. If the channel is in signalling, and the new mode is also signalling, then there's no MODE MODIFY.

In fact, the current code (after your patch) still gets it wrong, as far as I can tell. If I'm on a SDCCH, and the MSC sends an ASSIGNMENT CMD (signaling), then OsmoBSC is still sending a MODE MODIFY command which wants to "modify" a channel that's already in signalling to signalling. The test case gets it right by not expecting a modify here.

I think we need a check that can decide if a mode modify is necessary or not. I wonder if g_chan_nr or st can be used to determine the current channel mode.

I think we need a check in OsmoBSC to make sure a MODE MODIFY is only sent when needed (old mode != new mode).

I'm working on a new set of testcases (BSC_Tests.TC_ciph_mode_a5_{0,1,3}) and they all fail for the unrelated reason that OsmoBSC is sending a MODE MODIFY where none is needed. See attached PCAP file.

I have a quick question about the BSC_Tests.TC_ciph_mode_a5_{0,1,3} testcases:

/* Establish signalling channel (non-assignment case) followed by cipher mode */
private function f_tc_ciph_mode_a5(charstring id) runs on MSC_ConnHdlr {
    var template PDU_BSSAP exp_compl := tr_BSSMAP_AssignmentComplete(omit, ?);
    var BSSMAP_IE_AoIP_TransportLayerAddress tla := valueof(ts_BSSMAP_IE_AoIP_TLA4('01020304'O, 2342));
    var template PDU_BSSAP ass_cmd := valueof(ts_BSSMAP_AssignmentReq(omit, tla));
    ass_cmd.pdu.bssmap.assignmentRequest.channelType := valueof(ts_BSSMAP_IE_ChannelTypeSIGNAL);

    // Disable generation of ASSIGNMENT CMD, as OsmoBSC currently performs MODE MODFIY sign->sign (OS#2936)
    //f_establish_fully(ass_cmd, exp_compl);
    f_establish_fully(omit, exp_compl);
}

I am a bit confused about the two f_establish_fully() at the end. Do we really call f_establish_fully() two times or is f_establish_fully(omit, exp_compl) replaced with f_establish_fully(ass_cmd, exp_compl) when the problem is fixed. I guess so since "omit" indeed disables f_establish_fully() almost completely.

I have now integrated a check into f_establish_fully() that checks if the mode modify is expected or not. For this I check the channel number to see if we are on a signalling channel or not. BSC_Tests.TC_assignment_sign now passes nicely without any modification.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9231 MSC_ConnectionHandler: check channel mode in f_establish_fully

Also I have now re-enabled the generation of the BSSMAP ASSIGNMENT. However, for some reason the ASSIGNMENT COMPLETE is expected to include an AoIP transport address, which I think is not correct for a signalling channel. Also the ASSIGNMENT COMMAND should not contain one. I have corrected this now and the test passes fine. No MODE MODIFY is generated or expected by the test.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9232 BSC_Tests: fix TC_ciph_mode_a5_{0,1,3}

(Correct me if I am wrong, but from what I can see osmo-bsc decides correct since change: I86a2d52836c54d2dbd77441b182f757327ec7262)

I have rebased the two patches to current master. The fix for TC_ciph_mode_a5_{0,1,3} had a merge conflict, this is now fixed again. The function f_channel_needs_modify() is not perfect yet. I have added the fixme note as discussed on gerrit.

See also:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9231
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9232

The patches are merged and the tests

TC_assignment_sign
TC_ciph_mode_a5_0
TC_ciph_mode_a5_1
TC_ciph_mode_a5_3

are passing. I think this can be closed.