3G/UMTS

 

 

 

Enhanced Cell FACH

 

As the name stands for, Enhanced Cell FACH is an improved version of the conventional Cell FACH (If you are not familiar with the concept of conventional Cell FACH, refer to RRC State Change page). Assuming that you have at least a rough understanding of the conventional Cell FACH, let me as one thing. What would be the problems in the conventional Cell FACH ?

In my understanding and experience, the problems in conventional Cell FACH would be

  • Transistion Time from Cell FACH to Cell DCH is too long (due to signaling TTI used in R99)
  • Data rate on the Cell FACH is too low (just around 38 Kbps maximum)

Enhanced Cell FACH is a new technology to solve the problem mentioned above. Then, what is the logic behind the technology. The most important idea is to map Cell FACH onto HSPA channel. Since HSPA has much shorter TTI (usually 2 ms) comparing to R99 and data rate is much higher than R99 data rate, you can easily guess that Cell FACH mapped onto HSPA can improve the problems mentioned above. Enhanced Cell FACH was introduced in Release 7.

In 25.331 the feature is called HS-DSCH reception in CELL_FACH state. The UE receives the CCCH, the DCCH, the DTCH and even the BCCH on HS-DSCH, instead of on the FACH of an S-CCPCH. This page walks through the channel mapping first. Then it shows the two messages that switch the feature on: the UE capability in RRC Connection Setup Complete, and the common configuration in SIB5.

How are the channels mapped in Enhanced Cell FACH ?

Detailed understanding on how Enhanced Cell FACH requires detailed understanding of channel mapping for the technology. Overall channel mapping of Enhanced Cell FACH is as follows. (Compare this channel mapping to the conventional R99 Cell FACH : Channel Mapping - Cell FACH : R99/R5/R6)

 

Enhanced Cell FACH channel mapping of BCCH, PCCH, CCCH, DCCH and DTCH onto HS-DSCH through MAC flows and queues

Enhanced Cell FACH channel mapping. Every logical channel, including BCCH, PCCH and CCCH, reaches the UE on HS-DSCH/HS-PDSCH.

  • Top row : the logical channels with their rb-id and the LCID used on the FACH. BCCH 1 and PCCH 0 carry no rb-id. CCCH 0 has rb-id 0 and its LCID comes from SIB5. DCCH 0 to DCCH 3 are rb-id 1 to 4, and DTCH 1 is rb-id 8 with LCID 15.
  • MAC Flow Id = 1 : collects BCCH, PCCH, CCCH 0 and DCCH 0 into Queue 0.
  • MAC Flow Id = 2 : collects DCCH 1 to DCCH 3 into Queue 1, and DTCH 1 into Queue 2. The drawing labels both of these flows Id = 2.
  • Bottom : all queues end on the single HSDSCH/HSDPSCH transport and physical channel.

Why does the conventional mapping need to change? In R99 Cell FACH, the downlink logical channels go to FACH on an S-CCPCH, which has a long TTI and a low rate. Here the same logical channels go to MAC-ehs reordering queues and then to HS-DSCH. So the downlink gains the 2 ms TTI, HARQ and the higher HS-DSCH rates, while the UE stays in CELL_FACH without a dedicated physical channel.

  • No FACH on the downlink : every logical channel is carried on HS-DSCH.
  • MAC-ehs queues : the logical channels are grouped into reordering queues before HS-DSCH.
  • No DCH needed : the UE gets HSDPA rates while it stays in CELL_FACH.

How does the UE report Enhanced Cell FACH capability ?

The network must not send HS-DSCH in CELL_FACH to a UE that cannot receive it. So the first step is the UE capability, which the UE reports at connection setup. The capability sits deep inside the extension chain of the message.

Following is RRC Connection Setup Complete message showing UE capability for Enhanced Cell FACH

 

RRC Connection Setup Complete with the non-critical extension chain down to ue-RadioAccessCapability-v690ext

ue-RadioAccessCapability-v770ext with hsdschReception-CellFach and hsdschReception-CellUraPch set to true

RRC Connection Setup Complete. The Release 7 capability is found only after following the non-critical extensions down to v770.

  • Upper part : the message opens v370, v380, v3a0 and laterNonCriticalExtensions, and then continues through v3g0, v4b0, v590, v5c0 and v690 to the ueCapabilityContainer.
  • Lower part : the container continues to v770NonCriticalExtensions and ue-RadioAccessCapability-v770ext.
  • physicalChannelCapability : fddPhysChCapability, then downlinkPhysChCapability, holds the Release 7 fields.
  • Highlighted : hsdschReception-CellFach and hsdschReception-CellUraPch, both true.

In 25.331 these two fields belong to DL-PhysChCapabilityFDD-v770ext, next to hsdsch-physical-layer-category-ext, hsscchlessHsdschOperation and enhancedFdpch. Each field is ENUMERATED { true } and OPTIONAL, so an absent field means that the UE does not support the feature. The second field, hsdschReception-CellUraPch, goes one step further. It lets the UE receive paging on HS-DSCH in CELL_PCH and URA_PCH.

  • hsdschReception-CellFach : HS-DSCH reception in CELL_FACH, the core of Enhanced Cell FACH.
  • hsdschReception-CellUraPch : HS-DSCH reception in CELL_PCH and URA_PCH.
  • Absent means not supported : both fields are optional flags.

What does SIB5 carry for Enhanced Cell FACH ?

The UE capability alone does not activate anything. The cell also has to broadcast the common HS-DSCH configuration, because a UE in CELL_FACH has no dedicated configuration for its CCCH. 25.331 clause 8.5.37 uses this IE for the CCCH: when SIB5 does not include HS-DSCH common system information, the UE does not receive the CCCH on HS-DSCH.

Following is SIB5 showing the mapping for CCCH and some additional information labeled in LCID = SIB5 in the above illustration.

 

SIB5 v770 extension with HS-DSCH common system information and HS-DSCH paging system information

SIB5 v770 extension, harq-SystemInfo, common H-RNTI and BCCH specific H-RNTI

SysInfoType5-v770ext. The cell broadcasts everything a UE needs to receive CCCH, BCCH and paging on HS-DSCH before any dedicated setup.

  • ccch-MappingInfo : logicalChannelIdentity 5 and mac-ehs-QueueId 0. This is the LCID the diagram above labels LCID = SIB5.
  • common-MAC-ehs-ReorderingQueueList : two common queues, 0 and 1, each with t1-ReleaseTimer rt50 and mac-ehsWindowSize mws16.
  • hs-scch-SystemInfo : the HS-SCCH channelisation codes, here code 7.
  • harq-SystemInfo : 6 HARQ processes with implicit memory partitioning.
  • common-H-RNTI-information and bcchSpecific-H-RNTI : 0000000100100011 and 0000000000010010.
  • hs-dsch-PagingSystemInformation : one PICH on channelisation code 3 with 18 paging indicators per frame, HS-PDSCH channelisation code 1, three PCCH transmissions and TransportBlockSizeIndex 1.

The two H-RNTIs have different jobs. A UE without a dedicated H-RNTI picks one common H-RNTI from the list, using U-RNTI mod K, where K is the number of listed common H-RNTIs. The BCCH specific H-RNTI marks the HS-DSCH transmission that carries BCCH, such as a SYSTEM INFORMATION CHANGE INDICATION. The paging part is optional. It is present here, so this cell can also page UEs in CELL_PCH and URA_PCH on HS-DSCH.

* Additional information showing the mapping of other channels will be updated later.

  • SIB5 v770ext carries the common setup : queues, HS-SCCH codes, HARQ and H-RNTIs.
  • CCCH on LCID 5, queue 0 : the value the channel mapping above takes from SIB5.
  • Two kinds of H-RNTI : a common one per UE, and one for BCCH.

What was added after Release 7 ?

Release 7 fixed only the downlink. The uplink in CELL_FACH still used RACH with its R99 TTI, and a UE had to decode HS-SCCH all the time. Release 8 addressed both points with new extensions of the same SIB5.

The first addition is HS-DSCH DRX in CELL_FACH. SysInfoType5-v860ext adds hs-dsch-DrxCellfach-info with the timer t-321, a DRX cycle of 4, 8, 16 or 32 frames, and a receive burst length. The UE reports support with supportOfHsdschDrxOperation in DL-PhysChCapabilityFDD-v860ext. The second addition is Enhanced Uplink in CELL_FACH state and Idle mode, clause 8.5.45 of 25.331. For FDD, SysInfoType5-v8d0ext adds commonEDCHSystemInfoFDD, a pool of common E-DCH resources that a UE takes after a PRACH preamble. The UE reports support with supportOfCommonEDCH.

The two additions work together. While the UE holds a common E-DCH resource, it receives HS-DSCH continuously. When the enhanced random access process ends, the UE starts T321, which is 100, 200, 400 or 800 ms. After T321 expires, the UE receives HS-DSCH only in the frames of its DRX pattern. Release 11 went one step further. SIB22 can add hs-dsch-DrxCellfach-SecondDrx-info, a second and longer DRX cycle of up to 512 frames for FDD.

  • Release 7 : HS-DSCH on the downlink in CELL_FACH, CELL_PCH and URA_PCH.
  • Release 8 DRX : SIB5 v860ext, hs-dsch-DrxCellfach-info.
  • Release 8 uplink : common E-DCH resources in SIB5 v8d0ext for FDD.
  • T321 links the two : the UE starts DRX only after its common E-DCH activity ends.

Reference

[1] 3GPP TS 25.331 v19.0.1 - clauses 8.5.36, 8.5.37, 8.5.38, 8.5.45 and 8.5.49, and the ASN.1 of DL-PhysChCapabilityFDD-v770ext, HS-DSCH-CommonSystemInformation, HS-DSCH-PagingSystemInformation, SysInfoType5-v770ext-IEs, SysInfoType5-v860ext-IEs and CommonEDCHSystemInfoFDD