Cellular Network Infrastructure » Radio Access Network » OsmoBSC

please review the specs (or other information you can find online) regarding LCLS and try to summarize how it works in a small set of slides you can show to the team.

I have started to read and collect information about local call local switching.

• http://git.osmocom.org/osmo-bsc/log/?h=laforge/lcls for the BSC, as well as
• http://git.osmocom.org/osmo-ttcn3-hacks/log/?h=laforge/lcls on the test side.

both need quite some more work, but I think I've figured out the state machine with all of its transitions by now.

I've made significant progress on the testing side, although I hit a Titan compiler bug (see https://www.eclipse.org/forums/index.php/t/1093530/) as well as some shortcomings in our *_Emulation components, see https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9403/

during the first tests, it became apparent that wireshark wasn't able to decode LCLS specific PDUs. I've created a patch and submitted it at https://code.wireshark.org/review/#/c/27941/

the tests for LCLS related signaling are rather complete now, and they all pass with my latest version of the OsmoBSC LCLS FSM.

The only missing bit now is to actually implement the body of the functions that enable/disable the local switching of the voice, i.e. that issue the MGCP commands.

Thinking about it:

• enable LCLS for a given call
  • Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call A to point to IP/Port of call B
  • Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call B to point to IP/Port of call A
• disable LCLS for a given call
  • Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call A to point back to MSC/MGW
  • Issue MGCP MDCX on MSC-side connection on MGCP endpoint of call B to point back to MSC/MGW

So we have to cache the ip/port information of the MGW/MSC during ongoing local switching, as we don't receive that information [again] once we switch back.

Known limitation: Until the MGW can perform transcoding, calls with mis-matching codecs will break. We should add some provision into OsmoBSC that would prevent activating LCLS on two calls of different codecs until the MGW can transcode.

There will also be LCLS implications at the time we do inter-BSC hand-over. This will have to be looked into once inter-BSC HO is merged.

laforge wrote:

during the first tests, it became apparent that wireshark wasn't able to decode LCLS specific PDUs. I've created a patch and submitted it at https://code.wireshark.org/review/#/c/27941/

wireshark patch is already accepted / merged to master.

https://gerrit.osmocom.org/#/c/osmo-bsc/+/9416 has been updated. It now actually performs local switching via MGCP MDCX re-configuration of OsmoMGW.

The test suite in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9412 has equally been extended to verify the actual MGCP user plane switching functionality.

bsc code + testsuite has been merged to respective master branch, and VTY config option to enable/disalbe LCLS has been added. Working on CI execution of tests now.

Jenkins integration of test suite: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/

the only remaining bit is to ensure LCLS is not enabled on calls that have different codecs on both legs (at least until we have working transcoding in osmo-mgw).

As I'm leaving on holidays soon, it would be good if dexter could take care of this last missing bit, including related TTCN3 tests

I have now added a check that tests the two call legs for different codec/rate. If codec/rate is different, then LCLS will be avoided. However, I am a bit unsure about the status codes here. At the moment the status code I see is LCLS_STS_not_yet_ls. I am not sure if this is right, but it must be the same as with the other conditions in lcls_enable_possible()

See also:
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9940 lcls: do not LCLS call legs with different codecs
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9941 BSC_Tests_LCLS: try call legs with different codec/rate

if it's at 100%, it can be resolved.

Its not fully done yet. There is one patch that is still in review: https://gerrit.osmocom.org/#/c/osmo-bsc/+/9940/

The patch is through. I think we are now done here.

The TTCN3 test (TC_lcls_gcr_bway_codec_mismatch) that tests this still does not pass, we need to check why.

The reason why TC_lcls_gcr_bway_codec_mismatch does not pass anymore is because there were API changes and LCLSs was using abandoned struct members. This is now fixed.

See also: https://gerrit.osmocom.org/#/c/osmo-bsc/+/10905

The patch is through, but on jenkins one can see that now the following LCLS related tests are failing:

TC_lcls_connect_break
TC_lcls_connect_clear
TC_lcls_gcr_bway_connect
TC_lcls_gcr_bway_connect_hr

This might be unrelated to this issue, but we certainly must check this. It is also very suspicious that just when TC_lcls_gcr_bway_codec_mismatch stops failing the others start to fail.

I'll close this issue as LCLS support is implemented. That fact that either our test suite or the implementation still has a bug doesn't change that fact.

Yes, lets close it. The TTCN3 tests also pass fine now.