Project

General

Profile

Feature #3777

Support CSFB "Fast Return"

Added by laforge over 2 years ago. Updated over 2 years 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"Resolved02/03/2019

Associated revisions

Revision 963763df (diff)
Added by laforge over 2 years ago

Implement CSFB "Fast Return" Handling at RR RELEASE

When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.

We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.

That in turn will make sure the MS/UE can return very quickly to
the LTE cell.

Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1

History

#1 Updated by laforge over 2 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?

#2 Updated by laforge over 2 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 :/

#3 Updated by laforge over 2 years ago

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

#5 Updated by laforge over 2 years 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 over 2 years 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 over 2 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.

#8 Updated by laforge over 2 years ago

patch merged to master. TTCN3 patch still pending.

#9 Updated by laforge over 2 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)