Support CSFB "Fast Return"
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 220.127.116.11)
- 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 18.104.22.168 + 22.214.171.124)
Let's use this ticket to collect all relevant details and head towards and implementation in OsmoBSC
#1 Updated by laforge about 2 months 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?
#2 Updated by laforge about 2 months 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 :/
#4 Updated by laforge about 2 months 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.
#6 Updated by laforge about 2 months 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.