Enhanced Cell_FACH in DL

Enhanced Cell_FACH in DL:

Enhanced Cell_FACH in DL is introduced in Rel-7 with the following functionalities:

1. HS-DSCH resources can be assigned to UE in Cell_FACH State
2. UE no longer need to monitor FACH - SCCPCH channel for DL data, instead UE can monitor HS-SCCH channel in Cell_FACH State

Why Enhanced Cell_FACH in DL:

In legacy Release Cell_FACH has the following issues:

1. Low data rate on FACH 
2. QoS cannot be maintained on FACH
3. If there is a burst of data to be transmitted to or from UE then NW may first move UE to Cell_DCH State and this involve unnecessary signalling and latency.
4. Frequent switching between Cell_FACH <-> Cell_DCH leads to more battery consuption
5. UE needs to continuously monitor S-CCPCH physical channel to receive data on FACH TrCH

Configuration of Enhanced Cell_FACH in UE

Configuration of HS-DSCH in CELL_FACH State is done as follows:

NW needs to broadcast the following IEs in SIB - 5:

- HS-DSCH Common System Information
- HS-DSCH Paging System Information

HS-DSCH Common System Information:

This IE contains information related to configuration of HS-DSCH in CELL_FACH State

• CCCH Mapping Info

     ccch-MappingInfo                   CommonRBMappingInfo,
   * srb1-MappingInfo                   CommonRBMappingInfo OPTIONAL,
     common-MAC-ehs-ReorderingQueueList Common-MAC-ehs-ReorderingQueueList,
     hs-scch-SystemInfo                 HS-SCCH-SystemInfo,
     harq-SystemInfo                    HARQ-Info,
     common-H-RNTI-information          SEQUENCE (SIZE(1..maxCommonHRNTI)) OF H-RNTI,
     bcchSpecific-H-RNTI                H-RNTI

Physical Channel Configuration (Part - II)

DL HS - PDSCH Information: 
This IE contains information about High Speed Physical Downlink Shared Channel.

• HS - SCCH Info: (High Speed - Shared Control Channel) The HS-SCCH is a fixed rate (60 kbps, SF=128) downlink physical channel used to carry downlink signalling related to HS-DSCH transmission
• HS - SCCH Channelisation Code Info
• 1 to MAX HS-SCCHs = 4 (At max UE can be configured to monitor 4 HS-SCCH channels simultaneously)
• Codes 0 to 127
• DL Scrambling Code:
• Generally DL scrambling Code for HS-SCCH & HS-PDSCH reception is same as Primary Scrambling Code (PSC), but NW may map HS-SCCH and HS-PDSCH channels on Secondary Scrambling Code (SSC), hence this IE is needed.
• Measurement Feedback Info: This IE is used to configure the measurement done by UE related to Quality of HS-PDSCH channel. Measurement are done by physical layer. This measurement is reported by Physical layer on UL HS-DPCCH channel to NW directly.
• Measurement Power Offset
• Feedback Cycle
• CQI Repetition Factor
• Delta CQI
• DL 64 QAM Configured:
• Boolean Variable to indicate if 64 QAM is configured or not.
• 64 QAM is basically used to increase DL data rate
• HS-DSCH TB Size Table: Used when MAC-ehs is configured
• OCTET Aligned or BIT Aligned

UL DPCH Info: 
This IE contains information about UL Dedicated Physical Channel.

• UL DPCH Power Control Information: Basically needed when Sync Procedure A or AA is needed.
• DPCCH Power Offset:
• When establishing the first DPCCH in CELL_DCH the UE shall start the UL inner loop power control at a power level according to:
• DPCCH_Initial_power = DPCCH_Power_offset – CPICH_RSCP
• Where
• DPCCH_Power_offset shall have the value of IE "DPCCH Power offset" in IE "Uplink DPCH power control info"
• The value for the CPICH_RSCP shall be measured by the UE.
• PC Preamble: 
• This IE gives number of Frames Npcp.
• This is basically used to introduce delay between DPCCH and DPDCH/E-DPCCH/E-DPDCH 
• The transmission of the uplink DPCCH power control preamble shall start Npcp radio frames prior to the radio frame where the uplink DPDCH/EDPCCH/E-DPDCH transmission starts, where Npcp is a higher layer parameter set by UTRAN
• The transmission start delay between DPCCH and DPDCH/E-DPCCH/E-DPDCH may be cancelled using a power control preamble of 0 length
• SRB Delay:
• To Delay the transmission on SRB0 to SRB4 by number of frames indicated in SRB Delay or while Physical channels are not considered established
• Power Control Algorithm
• Delta ACK
• Delta NACK
• ACK - NACK repetition factor
• Above three IEs are used to set the uplink HS-DPCCH power relative to DPCCH power
• HARQ Preamble Mode
• Scrambling Code Type - long or short
• Scrambling Code:
• Used to identify the UE in UL
• Number of DPDCH:
• MAX UL DPDCH = 6
• Value 0 may only be used if target configuration has no uplink DPDCH, i.e. E-DCH is configured
• Spreading Factor
• TFCI Existence
• No. of FBI Bits
• No. of TPC bits
• Puncturing Limit

Physical Channel Configuration - Part I

Detailed description of Physical Channel Configuration IEs contained in any RRC Reconfiguration Message.

DL COMMON RL INFO:

Downlink common RL information contains the following IEs:

• DPCH Common Info
• CFN Handling: Initialize or Maintained
• Initialize - HHO needs to be performed
• Maintained -  
• The purpose of the Timing-maintained hard handover procedure is to remove all the RL(s) in the active set and establish new RL(s) while maintaining the CFN in the UE.
• This procedure can be initiated only if UTRAN knows the target SFN timing before hard handover. The target SFN timing can be known by UTRAN in the following 2 cases:
• UE reads SFN when measuring "Cell synchronisation information" and sends it to the UTRAN in MEASUREMENT REPORT message.
• UTRAN internally knows the time difference between the cells
• Timing Maintained Sync Ind - TRUE indicate that UE don't need to perform Physical Sync Procedure - A during timing maintained HHO procedure.
• DL DPCH Power Control Info - DL Power Control Mode
• Power offset P Pilot-DPDCH
• Spreading Factor and Pilot Bits
• Position: Indicate fixed or flexible positions of the TrCHs in the radio frame 
• TFCI Existence: 
• TRUE indicates that TFCI is used. 
• When spreading factor is less than or equal to 64, FALSE  indicates that TFCI is not used and therefore DTX is used in the TFCI field (i.e. in DL - DPCCH Physical Channel)
• Absence of TFCI bits indicates Blind Transport Format detection. Basically used for fixed data rate services.

• F-DPCH Common Info
• CFN Handling: Initialize or Maintained
• Initialize - HHO needs to be performed
• Maintained -  
• The purpose of the Timing-maintained hard handover procedure is to remove all the RL(s) in the active set and establish new RL(s) while maintaining the CFN in the UE.
• This procedure can be initiated only if UTRAN knows the target SFN timing before hard handover. The target SFN timing can be known by UTRAN in the following 2 cases:
• UE reads SFN when measuring "Cell synchronisation information" and sends it to the UTRAN in MEASUREMENT REPORT message.
• UTRAN internally knows the time difference between the cells
• Timing Maintained Sync Ind - TRUE indicate that UE don't need to perform Physical Sync Procedure - A during timing maintained HHO procedure.
• DL FDPCH Power Control Info - DL Power Control Mode
• DL FDPCH TPC Command Error Rate

• Default DPCH Offset: (Ref: 3GPP TS 25.402)
• The DOFF FDD (FDD Default DPCH Offset value) is used to define Frame Offset and Chip Offset at first RL setup. The resolution should be good enough to spread o ut load over Iub and load in Node B (based on certain load distributing algorithms). In addition it is used to spread out the location of Pilot Symbol in order to reduce the peak DL power since Pilot symbol is always transmitting at the fixed location within a slot (the largest number of chips for one symbol is 512 chips).
• The SRNC sends a DOFF FDD parameter to the UE when the new RL will make the UE change its state (from Cell_FACH state or other when coming from another RAN) to Cell_DCH state.
• Resolution: 512 chips; Range:0 .. 599 (< 80 ms).
• DPCH Compressed Mode Info
• Transmit Diversity Mode 
• MAC-hs Reset Indicator
• To flush all hadpa bufffers
• Typically set by NW when serving cell is changed between different Node - B's, as MAC-hs buffers cannot be moved to new serving cell.
• Post Verification Mode
• To perform Fast L1 synchronization, where while waiting for physical synchronization, other layers are configured and physical sync is done in parallel.

DL INFORMATION FOR EACH RL:

DL Information for each RL contains the following IEs:

• Primary CPICH Info -> Primary Scrambling Code: To Identify the RL
• Serving HSDPA RL Indicator
• Serving EDCH RL Indicator
• Both above IEs indicate if this RL is the serving RL
• Serving EDCH RL and Serving HSDPA RL has to be same
• DL DPCH Info Per RL
• PCPICH usage for channel estimation
• Indicate if PCPICH channel of this RL / Cell can be used in channel Estimation 
• DPCH Frame Offset
• used to determine the beginning of the DPCH or F-DPCH frame
• For the case of establishment or timing re-initialized HHO NW should follow the following restriction:
• (Default DPCH Offset Value) mod 38400 = DPCH frame offset(j)
  - where j indicates the first radio link listed in the message and the IE values used are the Actual Values of the IEs
• This means timing of the RLS is maintained or taken from the first RL in the list.
• i.e. for first RL DOFF and DPCH Frame Offset must be same.
• Once DPCH or F-DPCH is established NW should not change the timing, if really required then NW may ask UE to adjust the timing by +256 chips, any other value is an invalid configuration.
• Secondry CPICH Info:
• Secondry Scrambling Code
• ChannelizationCode
• This IE if present may be used by UE for Channel Estimation of this RL.
• UE may use pilot bits of DPCCH for channel estimation.
• Generally UE will use Pilot bits on DPCCH for channel estimation.
• DL Channelization code list
• Channelization code of the RL
• TPC Combination index
• RLs having same combination index have same TPC bits
• RLs having same combination index as Serving RL belong to serving RLS
• For EDCH, RL having same combination index have same Acknowledgement feedback Signal on E - HICH.
• Power Offset TPC
• Closed loop timing adjustment mode
• DL F-DPCH Information per RL
• Primary CPICH usage for channel estimation
• NW may configure Primary CPICH for channel estimation
• UE may still use Pilot bits on DPCCH for channel estimation
• F-DPCH Frame Offset
• same as above 'DPCH Frame offset'
• F-DPCH Slot format
• Indicate slot format of F-DPCH, if not included the Slot format 0 is taken
• Secondary CPICH Info: same as above
• Secondary Scrambling Code:
• This indicate if F-DPCH is mapped on Secondary Scrambling Code
• DL Channelization code
• TPC Combination Index: same as in DPCH case
• STTD Indication

Note: Either DPCH or FDPCH can be configured by NW, and not both.

• E - AGCH Information: 
• This IE contains information about EDCH Absolute Grant Channel
• The E-DCH Absolute Grant is transmitted by a single cell, the Serving E-DCH cell on this physical channel. Hence AGCH is configured only for serving E-DCH Cell.
• It includes only one IE:
• E- AGCH Channelization code
• E - HICH Info (E-DCH HARQ acknowledgement Indicator Channel)
• E-HICH Channelization Code
• Signature Sequence
• Release indicator
• The E-DCH ACK/NACKs are transmitted by each cell of the E-DCH active set on this physical channel. The E-HICHs of the cells belonging to the same RLS (same MAC-e entity i.e. same Node B) shall have the same content and modulation and be combined by the UE.
  NOTE: The set of cells transmitting identical ACK/NACK information is the same as the set of cells sending identical TPC bits (excluding the cells which are not in the E-DCH active set).
• E - RGCH Info
• E-RGCH Combination Indes
• Signature sequence
• E-RGCH Channelization code is same as E-HICH channelization code, hence to differentiate both physical channels different Signature Sequence are allocated to both channels.
• The E-DCH Relative Grants are transmitted by each cell of the E-DCH active set on this physical channel
• Serving RLs: The E-RGCHs of the cells belonging to the serving RLS shall have the same content and be combined by the UE. 
• Non Serving RLs: The E-RGCHs of the cells not belonging to the serving E-DCH RLS are cell specific and cannot be combined:
• Cell ID
• This information element identifies a cell unambiguously within a PLMN

Signalling Radio Bearer 5 (SRB5)

SRB - 5 has been introduced in order to support quick changes in Multi-mode AMR or Wideband AMR data rate

SRB - 5 exist in UL & DL with the following characteristics:

• RB Id, can be any number between (5 - 31)  - SRB#5 need not have RB - ID 5, it can be any RB ID allocated by UTRAN
• UL RLC Mode = TM - DCCH is mapped to TM RLC
• DL RLC Mode = TM - DCCH is mapped to TM RLC
• TB Size  = 3 bits - currently only 3 – bit message is defined
• TBS =  0x3, 1x3
• It is mapped to a DCH TrCH different from DCH of SRB 1 to 4.

Until now only one message has been defined in standard i.e. "Transport Format Combination Control" which is send by UTRAN on TM RLC mode.

Transport Format Combination Control (TFCC):

When this message is sent on TM RLC Mode, i.e. on SRB#5, this message has special handling and encoding:

• This message is NOT ASN.1 encoded
• This message is encoded tabular format.
• Currently only 3 – bit tabular format is defined as below:

3	2	1	Transport Format Combination Sub Set Identity value
0	0	0	0
0	0	1	1
-	-	-	-
1	1	1	7

• There is no response to this message
• If UE receives this message and the TFC Subset id is out of range or more than the subsets that UE has then UE ignores this message and behave as if no such message is received.

 Typical Scenario to use SRB#5:

1. CS call is established for Multi – Mode AMR (12.2/7.95/5.9/4.75 kbps)

2. Typical RB Setup message would include:
1. Complete TFCS list for all  data rates 12.2/7.95/5.9/4.75 kbps
2. TFC Subset for specific data rate 12.2 / 7.95 / 5.9 / 4.75 kbps (four subsets)

3. In order to change the data rate to (say 5.9 kbps), UTRAN would send  TFCC message on RLC – TM mode only indicating TFC Subset to be uses, as in our example it would be “2”, indicating third TFC subset to be used

4. UE RRC would receive this message on TM – RLC; no ASN.1 decoding is needed for this message.

5. RRC should configure it lower layers as per the given TFC Subset in the received 3 – bit message

Serving Radio Network Subsystem (SRNS) Relocation

SRNS Relocation is a procedure executed at UTRAN side where by:

• Serving RNC is shifted from Current Serving RNC to Controlling RNC, .i.e. Iu signalling connection is shifter from current SRNC to the CRNC. After this CRNC becomes the Serving RNC.
• This may happen when UE sends measurement report to change serving cell, and this new serving cell belongs to different CRNC
• On reception of Meas Report NW may decide to perform Serving Cell Change with SRNS relocation
• At times SRNC and CRNC for a UE may be same or different.

SRNC and CRNC is the terminology used with respect to a UE. 

Serving RNC (SRNC):

• Serving RNC is that RNC where the Iu signalling connection terminates between RNC and the Core NW.

Controlling RNC (CRNC):

• Controlling RNC is that RNC which provides physical resources to the UE. In other words, CRNC controls and owns the resources of the cell to which UE is connected.

To perform SRNS relocation UTRAN may include the following IEs in any reconfiguration message with the following restriction:

•  if the reconfiguration procedure is simultaneous with SRNS relocation procedure:
• if the transmitted message is a RADIO BEARER RECONFIGURATION:
• include the IE "New U-RNTI".
• else:
• include the IE "Downlink counter synchronisation info".

Downlink Counter Synchronization Info:

DL Counter Sync Contains two IEs:

1. RB with PDCP SN Info: This contains two IEs as:
• RB ID
• RPCP Seq NO Info
• This IE is included for each RB having PDCP and lossless SRNS Relocation is needed for that RB.
• In order to perform lossless SRNS relocation, UTRAN provides a PDCP Seq no from where the transmission starts after relocation is done
2. RB with PDCP Context relocation: This contains three IEs as:

• RB ID
• DL RFC 3095 context relocation
• UL RFC 3095 context relocation
• RFC 3095 is basically used for ROboust Header Compression (ROHC)
• The context reinitialization MUST be done for all contexts at the compressor.
• This parameter may for instance be used to do context relocation at, e.g., a cellular handover that results in a change of compression point in the radio access network.

UE behavior on reception of DL-CounterSynchronization Info:

• If the IE "PDCP SN Info" is included, the UE shall:
• transfer the sequence number to the PDCP entity for the radio bearer;
• configure the RLC entity for the radio bearer to stop i.e.
• Stop RLC entity for SRBs 1, 3 & 4
• Stop all RLC AM and UM entities for RBs whose PDCP SN is not included
• include the current PDCP receive sequence number and the radio bearer identity for the radio bearer in the variable PDCP_SN_INFO in the response message

      Note: RBs whose SN is Included in the IE "PDCP SN Info" is not STOPPED

• Else if PDCP SN Info is not included in the message
• Stop all RLC AM an UM entities, except SRB - 2
• SRB - 2 is re-established
• if the received message contains "ciphering mode info"
• If security is pending, then it is applied and response is sent with new ciphering configuration
• set the new uplink and downlink HFN component of COUNT-C of RB2 to MAX(uplink HFN component of COUNT-C of RB2, downlink HFN component of COUNT-C of RB2);
• increment by one the downlink and uplink values of the HFN of COUNT-C for RB2;
• calculate the START value
• include the calculated START values for each CN domain in the IE "START list" in the IE "Uplink counter synchronisation info";

After transmission of response message UE needs to wait for RLC ACK for completion of SRNS Relocation procedure in UE.

After reception of successful RLC ack UE shall:

• Configure all RBs to "Continue", except for SRB-2 if not stopped
• re-establish all RLC entities except SRB-2
• Initialize first 20 bits of HFN of the Count - C of all AM and UM RLC entities to the START value transmitted in the response message
• Initialize remaining bits of Count - C of all UM RLC entities to zero

New - URNTI:
UTRAN Radio Network Temporary Identity (URNTI), is an identity allocated to UE having an RRC Connection and identifies the UE with in sUTRAN

• Initially Allocated by UTRAN on RRC Conn Establishment
• During SRNS Relocation NW may allocate New - URNTI to the UE
• On reception of this IE UE needs to calculate START Value and include calculated START in the response message

HSDPA Concepts

The Configuration of HSDPA is as follows:


For the configuration of HSDPA, following logical and physical resources needs to be allocated to UE by UTRAN in any of the reconfiguration message:

1. AM / UM Mode RBs mapped on to HS-DSCH
2. HS-DSCH TrCH - with DCH or without DCH
3. HS-SCCH set
4. DL Info per RL containing F-DPCH or DPCH configuration 
5. HS-PDSCH configuration is given in HS-SCCH 

High Speed - Physical Downlink Shared Channel (HS-PDSCH):

• HS - PDSCH is a DL shared physical channel
• SF = 16, so at max only 16 HS-PDSCH physical channels can be allocated, but by doing so all physical resources (codes) of the cell get exhausted
• Number of HS-PDSCH channels has to be planned in such a way that a cells physical resources are utilized efficiently among dedicated and other common resources.
• Shared between all the UEs in a Cell

MAC-d flows:

• MAC-d flow is the flow of PDUs which are MAC-d multiplexed
• It is almost similar to DCH TrCH
• MAC-d flow signifies a specific QoS on which, logical channels of same QoS are mapped
• MAC-d flows are between MAC-d and MAC-hs or MAC-ehs

HARQ:

• Hybrid Automatic Repeat Request

HARQ Entiry:

• There is only one HARQ Entity per UE in UTRAN.
• The HARQ entity adds Queue ID, Transmit Sequence Number (TSN) and HARQ Process Identifier to the transmitted MAC- hs / MAC - ehs PDU
• There is one HARQ Entity in the UE, which process HARQ Process Identifier received on HS-SCCH associated with MAC - hs PDU received on HS-DSCH.
• Each received MAC - hs PDU is allocated to the HARQ Process, identified by HARQ Process Identifier of the MAC - hs PDU.

HARQ process:

• HARQ Process handles one MAC - hs / MAC - ehs PDU
• MaxHProcesses = Maximum number of H-ARQ processes = 8
• Each HARQ Process has SoftBuffer to store MAC- hs / ehs PDUs

TX / UTRAN side:

• The HARQ process sets the New data indicator in transmitted MAC-hs PDUs. UTRAN should:
• set the New Data Indicator to the value "0" for the first MAC-hs PDU transmitted by a HARQ process;
• not increment the New Data Indicator for retransmissions of a MAC-hs PDU;
• increment the New Data Indicator with one for each transmitted MAC-hs PDU containing new data.
• The HARQ process processes received status messages. UTRAN should:
• deliver received status messages to the scheduler.

RX / UE side:

• HARQ Process, process the New Data Indicator associated with each MAC - hs PDU, indicated by Lower layers

If the MAC-hs PDU is received within 5 sub-frames from the reception of the previous MAC-hs PDU intended for this HARQ process; 

• discard the MAC-hs PDU.

When operating in CELL_DCH state, or in CELL_FACH state with a dedicated H-RNTI, if the MAC-ehs PDU is received within 5 sub-frames from the reception of the previous MAC-ehs PDU intended for this HARQ process:

• discard the MAC-ehs PDU.

=> This means each HARQ Process can be scheduled only once in 5 Sub-frame


1 Radio Frame = 10 ms
1 Radio Frame = 15 slots
1 Sub - Frame = 3 Slots = 2ms
1 Slot = 2560 chips