4G/LTE - Protocol

 

 

 

Redirection

 

To be honest, I don't know how to clearly define this word "Redirection" even though we pretty often use this terminology. Just based on my personal understanding, "Redirection" is the mechanism of chaning cells from one (let's call this 'serving/source cell') to another (let's call this 'target cell') at a specific point in the call process where RRC Session has initiated but it is before initiating Radio Bearer Setup.

Actually there are so many different cases where UE has to select or change cells in various points during the call processing and the terminology for the cell changes gets different depending on when the cell change happens. For example, if the cell change (in this case I would say 'picking up a cell among various candiate', so the term 'change' would not be the right one) happens when you power on a UE, we call the process 'Cell Selection'. If the cell change happens while UE is in idle mode, we call it 'Cell Reselection'. and if the cell change happens while UE is in communication mode after radio bearer setup, we call it 'Handover'.

Actually 'Redirection' is not the unique cocept in LTE, we have been using this concept almost all the technology.

In LTE, redirection means one specific tool, the redirectedCarrierInfo field of RRCConnectionRelease. The eNB releases the RRC connection and tells the UE which carrier, and which RAT, to search when it selects a cell again. Let's look at a typical run first, then at two captured messages, and then at the full list of targets in the current release.

How does a typical redirection run ?

CS fallback is the most common reason for a redirection, so it is the easiest place to see one. The UE asks for a CS call, the MME tells the eNB to move the UE, and the eNB answers with a release instead of a handover. The table below is the short version, and the steps after it fill in the network side.

The typical procedure for Redirection in LTE is as follows : (Note that the initial state is "Connected Mode in source cell" and the final state is the "Idle mode in target cell")

 

Direction

Message/Process

Description

UE --> NW

Extended Service Request

 

UE <-- NW

RRC Connection Release

Indicate which cell UE has to connect

UE <--> NW

< Registration to Target Cell >

 
 

< IDLE in Target Cell >

  

 

The network side follows 23.272 v20.0.0. For a CS fallback to 1xRTT in active mode, clause B.2.2 gives the order. The UE sends an Extended Service Request for mobile originating 1xCS fallback to the MME. The MME sends S1-AP UE Context Modification Request with the CS Fallback Indicator, which tells the eNB to move the UE to 1xRTT. The eNB may first ask the UE for a 1xRTT measurement report. It then triggers RRC connection release with redirection to 1xCS, and asks the MME to release the S1 UE context. The MME suspends the non-GBR bearers and deactivates the GBR bearers, and the UE sets up its call in the 1xRTT network.

CS fallback to GERAN or UTRAN has the same shape in clause 6.3. There the eNB chooses between three tools. The first is an inter-RAT cell change order to GERAN. The second is a release with redirection. The third is a release with redirection plus the system information of one or more target cells. When the MME marks the request as CSFB High Priority, the eNB also sets the release cause to cs-FallbackHighPriority.

  • Redirection releases the connection : the UE leaves RRC_CONNECTED and finds the target by cell selection, so no target cell is prepared in advance.
  • The MME asks, and the eNB chooses the tool : the CS Fallback Indicator only says that the UE must move. The eNB decides between handover, cell change order and redirection.
  • Redirection can also come after bearer setup : in CS fallback from active mode the UE already has EPS bearers, and the MME suspends them.

What do the Extended Service Request and RRC Connection Release look like ?

The two captures below come from one 1xCS fallback call. The red lines mark the fields that make it a CS fallback. In the NAS message these are the service type and the CSFB response. In the RRC message it is the redirection target.

I think just showing the one example of the contents of these message would be worth several pages of explanation.

 

< Extended service request >

 

Capture : EXTENDED SERVICE REQUEST, shown as a decoder tree. The values come from one recorded exchange and not from the specification.

NAS_LTE:EMM,Extended service request
Extended service request ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Extended service request message identity ::= V
  | +-Message type ::= MSG [4C]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0]
  +-Service type ::= V
  | +-Service type value ::= CHOICE [mobile originating CS fallback or 1xCS fallback]
  +-M-TMSI ::= LV
  | +-Octet1 ::= DIVISION
  | | +-Length of mobile identity contents ::= LEN (0..255) [0]
  | +-Octet2 ::= DIVISION
  | | +-Identity digit 1 ::= INT (0..15) [0]
  | | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the TMSI/P-TMSI is used]
  | | +-Type of identity ::= CHOICE [No Identity]
  | +-Octet3-Octet6 ::= DIVISION
  |   +-Identity digit p ::= OCTETARRAY SIZE(0..4)
  +-CSFB response ::= TV OPTIONAL:Exist
    +-Octet1 ::= DIVISION
      +-CSFB response IEI ::= IEI [B-]
      +-spare ::= FIX [0]
      +-CSFB response value ::= CHOICE [CS fallback accepted by the UE]

Two points in this capture disagree with 24.301 v20.0.0. The service type is "mobile originating CS fallback or 1xCS fallback", which matches the call. But the message also carries the CSFB response IE, set to "CS fallback accepted by the UE". Clause 8.2.15.2 says that the UE includes this IE only when the service type is "mobile terminating CS fallback or 1xCS fallback". The M-TMSI field is also empty, with length 0 and type of identity "No Identity". In 24.301 the M-TMSI is a mandatory LV field of 6 octets, so this capture probably comes from a test setup.

 

< RRC Connection Release >

 

Capture : RRCConnectionRelease on DL-DCCH, shown as a decoder tree. The values come from one recorded exchange and not from the specification.

RRC_LTE:DL-DCCH-Message
DL-DCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [rrcConnectionRelease]
      +-rrcConnectionRelease ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [rrcConnectionRelease-r8]
            +-rrcConnectionRelease-r8 ::= SEQUENCE [100]
              +-releaseCause ::= ENUMERATED [other]
              +-redirectedCarrierInfo ::= CHOICE [cdma2000-1xRTT] OPTIONAL:Exist
              | +-cdma2000-1xRTT ::= SEQUENCE
              |   +-bandClass ::= ENUMERATED [bc2]
              |   +-arfcn ::= INTEGER (0..2047) [0]
              +-idleModeMobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

The release carries releaseCause other and redirectedCarrierInfo with the cdma2000-1xRTT choice, band class bc2 and ARFCN 0. So the eNB sends the UE to a 1xRTT carrier, as step 6a of 23.272 clause B.2.2 describes. The optional idleModeMobilityControlInfo is absent, so the UE gets no dedicated reselection priorities with this release. The decode also stops at rrcConnectionRelease-r8. Later additions such as cellInfoList-r9 and redirectedCarrierInfo-v9e0 are not used.

  • Both captures belong to a 1xCS fallback : the NAS service type and the RRC target, cdma2000-1xRTT, describe the same call.
  • A capture does not always follow the specification : this one carries a CSFB response IE, which 24.301 allows only in a mobile terminating request.

Where can RRCConnectionRelease send the UE ?

The capture uses one choice of the redirectedCarrierInfo field, but the field has grown with each release. The listing below is the current definition, together with RRCConnectionRelease-r8-IEs and ReleaseCause, which carry it.

Following is based on 36.331 v19.3.0 (Release 19)

RRCConnectionRelease-r8-IEs ::=		SEQUENCE {
	releaseCause						ReleaseCause,
	redirectedCarrierInfo				RedirectedCarrierInfo				OPTIONAL,	-- Need ON
	idleModeMobilityControlInfo			IdleModeMobilityControlInfo			OPTIONAL,	-- Need OP
	nonCriticalExtension				RRCConnectionRelease-v890-IEs		OPTIONAL
}

ReleaseCause ::=				ENUMERATED {loadBalancingTAUrequired,
											other, cs-FallbackHighPriority-v1020, rrc-Suspend-v1320}

RedirectedCarrierInfo ::=			CHOICE {
	eutra								ARFCN-ValueEUTRA,
	geran								CarrierFreqsGERAN,
	utra-FDD							ARFCN-ValueUTRA,
	utra-TDD							ARFCN-ValueUTRA,
	cdma2000-HRPD						CarrierFreqCDMA2000,
	cdma2000-1xRTT						CarrierFreqCDMA2000,
	...,
	utra-TDD-r10						CarrierFreqListUTRA-TDD-r10,
	nr-r15								CarrierInfoNR-r15,
	nr-r17								CarrierInfoNR-r17,
	nr-NTN-r19							CarrierInfoNR-r19,
	eutra-NTN-r19						CarrierInfoEUTRA-r19,
	nbiot-NTN-r19						CarrierInfoNB-r19
}

The first six choices are from Release 8, one for each RAT that LTE supported at launch. The choice utra-TDD-r10 carries a list of UTRA TDD carriers instead of one. The choices nr-r15 and nr-r17 redirect the UE to NR, and Release 19 adds three NTN choices, for NR, E-UTRA and NB-IoT. The field names a carrier, not a cell. So the UE still runs cell selection, as 36.304 clause 5.2.7 describes. It first tries to camp on a suitable cell on the indicated carrier. If it finds none, it may camp on any suitable cell of the indicated RAT. Without redirectedCarrierInfo, it looks for a suitable cell on an E-UTRA carrier.

Security also limits the targets. If AS security is not active, the UE ignores a redirection to NR. Upper layers can also forbid a redirection to GERAN or UTRAN without AS security, and the UE then ignores the whole release content.

  • The target is a carrier, not a cell : the UE runs cell selection on the carrier, and then on any suitable cell of that RAT.
  • The list of targets keeps growing : NR arrived in Release 15, and Release 19 adds NTN targets for NR, E-UTRA and NB-IoT.
  • Security limits some targets : without AS security the UE ignores a redirection to NR.

Reference

  • 36.331 : 3GPP - E-UTRA Radio Resource Control (RRC); Protocol specification, v19.3.0. Clause 5.3.8.3, RRCConnectionRelease, ReleaseCause and RedirectedCarrierInfo.
  • 36.304 : 3GPP - E-UTRA User Equipment (UE) procedures in idle mode, v19.2.0. Clause 5.2.7.
  • 24.301 : 3GPP - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3, v20.0.0. Clause 8.2.15, EXTENDED SERVICE REQUEST.
  • 23.272 : 3GPP - Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2, v20.0.0. Clauses 6.3 and B.2.2.