Feature #3777
closedSupport CSFB "Fast Return"
100%
Description
In CSFB, there's an optional mechanism called "Fast Return", which ensures a smooth/fast transition after the CS call back to the LTE network.
I couldn't yet find a good description of this mechanism, but rather bits of information are spread across multiple specs.
- The MSC sends the "CSFB indication" IE as part of BSSMAP CLEAR COMMAND on the A interface (see TS 48.008 3.2.2.121)
- The MSC sends the "Last used E-UTRAN PLMN ID" as part of the BSSMAP COMMON ID on the A interface (see TS 48.008 3.2.1.68 + 3.2.2.127)
Let's use this ticket to collect all relevant details and head towards and implementation in OsmoBSC
Files
Related issues
Updated by laforge about 5 years ago
So allegedly, in fast return, the BSC is sending some kind of LTE frequency/cell information when releasing the RR connection. However, even in Release 15 of 3GPP TS 44.018 describing the GSM RR protocol, I don't see any information elements that could be used to convey this message.
I can however find various references in the UMTS RRC protocol. So maybe fast return is only specified from UTRAN -> EUTRAN but not from GERAN -> EUTRAN?
Updated by laforge about 5 years ago
ok, reading the "procedures" part of 44.018 gives us some clue:
If the network redirects a mobile station towards E-UTRAN, it proceeds as follows:
- The network shall use the information element "Cell selection indicator after release of all TCH and SDCCH" in the channel release message for redirection towards an EARFCN in the E-UTRAN band numbered less than 65.
- The network shall use the information element "individual priorities" in the channel release message for redirection towards an EARFCN in the E-UTRAN band numbered greater than 64.
So we have to look primarily at 10.5.2.1e for the more relevant band numbers < 64. It's CSN.1 encoded :/
Updated by laforge about 5 years ago
- Related to Feature #3778: Support CSFB "Fast Return" added
Updated by laforge about 5 years ago
The next question is whether we should (at least as an initial implementation) simply use the E-ARFCNs from the SI2quater neighbor list and send it for the fast return to LTE. For sure those frequencies are a good start. The decision could probably be done more intelligently at some later point - but small networks will only have one frequency anyway.
Updated by laforge about 5 years ago
- Status changed from New to In Progress
- Assignee changed from 4368 to laforge
I've posted an initial (untested) patch in https://gerrit.osmocom.org/#/c/osmo-bsc/+/12788
Will be working on a TTCN-3 test for it next.
Updated by laforge about 5 years ago
- File BSC_Tests.TC_chan_rel_hard_clear_csfb.pcap BSC_Tests.TC_chan_rel_hard_clear_csfb.pcap added
- % Done changed from 0 to 60
I just updated the patch, and was able to generate the following result from a new TTCN-3 test, see attached PCAP file. This was with a single LTE neighbor configured in si2quater.
Updated by laforge about 5 years ago
- % Done changed from 60 to 90
I'd say together with the test, this is rather complete. Let's wait for the merge to master before closing.
Updated by laforge about 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
TTCN-3 patch is contained in TC_chan_rel_hard_clear_csfb() which was merged as Change-Id I7501fb25578412c882ff92da5d388f3079bbce7f in osmo-ttcn3-hacks.git
