Project

General

Profile

Feature #3777

Support CSFB "Fast Return"

Added by laforge 4 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/02/2019
Due date:
% Done:

100%

Spec Reference:

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.

  1. 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)
  2. 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


Related issues

Related to OsmoMSC - Feature #3778: Support CSFB "Fast Return"Resolved2019-02-03

History

#1 Updated by laforge 4 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 4 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 :/

#3 Updated by laforge 4 months ago

#4 Updated by laforge 4 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.

#5 Updated by laforge 4 months ago

  • Status changed from New to In Progress
  • Assignee changed from sysmocom 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.

#6 Updated by laforge 4 months ago

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.

#7 Updated by laforge 4 months 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.

#8 Updated by laforge 4 months ago

patch merged to master. TTCN3 patch still pending.

#9 Updated by laforge 3 months 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)