Feature #3777
closed
Support CSFB "Fast Return"
Added by laforge about 5 years ago.
Updated about 5 years ago.
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
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?
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 :/
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.
- Status changed from New to In Progress
- Assignee changed from 4368 to laforge
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.
- % 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.
patch merged to master. TTCN3 patch still pending.
- 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
Also available in: Atom
PDF
