Feature #3659
openhandover during LCLS directly between BTSs
Added by laforge over 5 years ago. Updated 11 months ago.
50%
Description
So far, we have implemented LCLS on the BSC level, i.e. in case of a local switch, the RTP stream still goes from BTS A to the BSC-colocated MGW and from there to BTS B. This removes the RTP/voice from A, but not from the Abis side.
In deployments where there are e.g. 3 BTS (A,B,C) at one site, back-hauled via Abis to a BSC in a remote data center, we want the voice to go directly between BTS A and BTS B, without going to the MGW at the BSC.
This basically means that we close the loop not inside our osmo-mgw via MGCP, but that we close it between the two involved BTSs.
Even in a single-remote-BTS use case, this helps in cases where both calling and called subscribers are attached to that same BTS.
Files
| lcls_bts_loop_experiment_with_osmo-bsc_and_osmo_msc_08012020.pcapng | lcls_bts_loop_experiment_with_osmo-bsc_and_osmo_msc_08012020.pcapng | 49.5 KB | dexter, 01/08/2020 10:49 AM |
Checklist
- add TTCN tests for RSL MDCX
- add RSL MDCX to BSC LCLS
- handle LCLS-MGW in handover
- handle LCLS-BTS in handover
- add TCCN test handover with LCLS-MGW
- add TCCN test handover with LCLS-BTS
Related issues
Updated by msuraev over 5 years ago
- Related to Feature #1602: BSC side of LCLS (local call local switching) as per the 3GPP specs added
Updated by msuraev over 5 years ago
- Status changed from New to In Progress
Preparing test setup using fake_trx/virtphy to check signalling locally.
Updated by msuraev over 5 years ago
On a related note: right now TTCN-3 TC_lcls_connect_clear() fails due to commit 6fe125294b219a519c77f7140de26870d17bf40a in OsmoBSC. Reverting just this commit doesn't fix it though so it's also affected by some changes in related commits as well.
The failing part in TC_lcls_connect_clear is probably CONN_A.receive(tr_RSL_DATA_REQ(?, tr_RslLinkID_DCCH(0), l3_rr_chan_rel)) due to missing "DATA REQuest (DTAP) (RR) Channel Release" packet - see difference in .pcap from https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/369/ and https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/370/
Updated by msuraev over 5 years ago
- % Done changed from 0 to 30
Implemented "lcls-mode bts-loop" in gerrit 11552, corresponding tests are in 11559 - WIP. Related preparation patches are under review.
Updated by msuraev over 5 years ago
- Related to Bug #3413: TC_lcls_connect_clear does not pass anymore. added
Updated by msuraev over 5 years ago
- Related to Feature #2487: MSC side of LCLS (local call local switching) as per the 3GPP specs added
Updated by msuraev over 5 years ago
- Checklist item add TTCN tests for RSL MDCX added
- Checklist item add RSL MDCX to BSC LCLS added
- Checklist item handle LCLS-MGW in handover added
- Checklist item handle LCLS-BTS in handover added
- Checklist item add TCCN test handover with LCLS-MGW added
- Checklist item add TCCN test handover with LCLS-BTS added
- % Done changed from 30 to 20
Updated by msuraev over 5 years ago
- Checklist item add TTCN tests for RSL MDCX set to Done
Updated by msuraev over 5 years ago
- % Done changed from 20 to 30
Almost all related libosmocore code is merged (except for gerrit 11703), TTCN-3 tests for RSL MDCX are merged but will fail until gerrit 11552 and 11550 are merged.
Updated by msuraev over 5 years ago
- Checklist item add RSL MDCX to BSC LCLS set to Done
Updated by msuraev over 5 years ago
- % Done changed from 30 to 40
- LCLS break works as intended (needs corresponding MSC code)
- both variants work fine when closing the loop between phones connected to different BTS (using osmocom-bb "stick" feature to use explicit ARFCN)
Remaining patches: libosmocore 7, OsmoBSC 4.
Updated by msuraev over 5 years ago
- Related to Feature #3586: support LCLS for inter-BSC handover added
Updated by msuraev over 5 years ago
- Related to Feature #1609: Inter-BSC hand-over is missing (MSC side) added
Updated by msuraev about 5 years ago
LCLS-BTS is not working when 2 phones are connected to different BTS: the loop is established but but no voice can be heard. Investigation is in progress.
Updated by msuraev about 5 years ago
- Related to Feature #3429: idea: auto-cleanup endpoints after long period of inactivity? added
Updated by msuraev about 5 years ago
- Related to Feature #3783: Make conn-timeout compatible with LCLS added
Updated by msuraev about 5 years ago
- Status changed from In Progress to Stalled
- % Done changed from 40 to 50
The test failure with 2 BSC connected to OsmoMSC could be reproduced using https://gerrit.osmocom.org/c/osmo-msc/+/13422 and related patches.
The unfinished implementation which simplifies troubleshooting is available in https://gerrit.osmocom.org/c/osmo-bsc/+/13419
Updated by laforge almost 5 years ago
- Assignee changed from msuraev to dexter
- Priority changed from Urgent to High
Updated by laforge almost 5 years ago
- Assignee changed from dexter to Hoernchen
Updated by dexter over 4 years ago
We have inspected the code now and the implementation looks more complete as expected. Even TTCN3 tests seem to be there:
BSC_Tests_LCLS.TC_lcls_bts_gcr_bway_connect
BSC_Tests_LCLS.TC_lcls_bts_gcr_bway_connect_hr
BSC_Tests_LCLS.TC_lcls_bts_connect_break
I have looked at the wireshark trace of TC_lcls_bts_gcr_bway_connect and it looks good. However I will give this also a try in a lab setup to see if it really works.
Updated by dexter over 4 years ago
- File lcls_bts_loop_experiment_with_osmo-bsc_and_osmo_msc_08012020.pcapng lcls_bts_loop_experiment_with_osmo-bsc_and_osmo_msc_08012020.pcapng added
I had a look at the osmo-msc code. Apparently we do not have support for LCLS there yet. At least during assignment the GCR and the other LCLS related info is not generated. I have added some hardcoded values here and then it works (see attached trace). I do not know if it is enough to set some static configuration for LCLS via VTY, at least the Node ID would be static. The GCR is probably more difficult. The MSC would need to correlate the incoming calls and assign equal GCRs to each pair of calls.
Updated by laforge almost 4 years ago
- Subject changed from LCLS directly between BTSs to handover during LCLS directly between BTSs
- Status changed from In Progress to New
- Assignee deleted (
dexter)
Updated by laforge almost 4 years ago
- Status changed from New to Feedback
- Assignee set to dexter
Updated by laforge almost 4 years ago
dexter wrote:
We have inspected the code now and the implementation looks more complete as expected. Even TTCN3 tests seem to be there:
can you please check with checklist items can then be checked off? Where are we in terms of this ticket overall status?
Updated by laforge almost 4 years ago
dexter wrote:
I had a look at the osmo-msc code. Apparently we do not have support for LCLS there yet.
This ticket is an OsmoBSC ticket; whether or not OsmoMSC supports it is not relevant. We can test in TTCN3.
Updated by keith over 1 year ago
I started some work on making LCLS with Handover fail better in https://gerrit.osmocom.org/plugins/gitiles/osmo-bsc/+/refs/heads/keith/LCLS_HO
As regards #2487 I'll add a note there.
Updated by laforge over 1 year ago
laforge wrote in #note-28:
can you please check with checklist items can then be checked off? Where are we in terms of this ticket overall status?
I would appreciate if anyone could help documenting the current status here (as checkbox items or otherwise), as I requested dexter to do two years ago. By now I assume everyone has lost all context and forgot about it. But it's important to know what is the status / expectation toward the current code.
Updated by dexter 11 months ago
In a recent discussion about this with keith the following idea came up: In the moment before handover the LCLS connection could be switched back to normal (full end to end path). Then the handover could be performed normally. After handover LCLS could be turned back on. This also makes sense since we do not know if LCLS could be performed at the target cell.
Updated by keith 11 months ago
Just to add, dexter I did make this switch off LCLS when HO starts and switch it back on HO complete "work" with a few simple lines of code.(branches mentioned in this and related tickets).
I think we need to inform the MSC though. it's not clear to me if the ttcn3 tests are implemented for that. Anyway, #note-29 notwithstanding, it's better for me to be able to test things against the actual MSC, so I would suggest an association of this ticket, to not say dependency with #2487
