Showing posts with label LTE System Information. Show all posts
Showing posts with label LTE System Information. Show all posts

LTE: Further enhanced Inter-Cell Interference Coordination: FeICIC


Cell Range Extension (CRE), Inter-Cell Interference Coordination (ICIC) and Enhanced Inter-Cell Interference Coordination (eICIC) were discussed in previous posts. FeICIC which is introduced in Release-11 will be discussed in detail in this post.

Introduction
The main idea behind CRE is to offload more traffic from macro cells to small cells and also to increase the HetNet efficiency. The range of the small cell is expanded by implementing a selection offset (UEs in idle mode) or handover threshold in measurement configuration (UEs in connected mode) in the favor of the small cell. A major problem is that, the UEs in CRE zone are forcibly being served by the small cell, but in reality, the downlink received power from the macro cell is higher than the small cell. So, there will be a severe downlink interference from the macro cell to UEs being served by the pico cell.

A number of features added to the 3GPP LTE specifications can be used to mitigate the above-mentioned interference problem in HetNets with small cells. Inter-cell interference coordination (ICIC) has the task to manage radio resources such that inter-cell interference is kept under control.

ICIC is introduced in 3GPP Release-8 specifications to mitigate interference on traffic channels only. Only frequency domain ICIC was prioritized which manages radio resources, notably the physical resource blocks (PRBs), such that multiple cells coordinate use of frequency domain resources. Support for X2 signalling is added for the co-ordination between cells that belongs to two different eNBs. The frequency domain ICIC doesn’t provide significant gain in Heterogeneous Networks (HetNets). This is due to the fact that with ICIC the provided Range Extension is limited as it applies only to data channels and not to control channels where interference can remain significant.

The enhanced ICIC (eICIC) is introduced in 3GPP LTE Release-10 to deal with interference issues in HetNets, and mitigate interference on traffic and control channels. eICIC feature increases the coverage area of the victim cells without boosting downlink power. While ICIC coordinates inter-cell interference in the frequency and power domains, eICIC coordinates inter-cell interference in time, frequency and power domains. The major change in eICIC is the addition of time domain ICIC. Time domain ICIC is realized through the use of Almost Blank Subframes (ABS). ABSs are subframes with reduced transmit power including no transmission on some physical channels and/or reduced activity.

Further enhanced Inter-Cell Interference Coordination (FeICIC)
The eICIC scheme introduced in Release-10 did not address interference caused by cell-specific reference signals (CRS), synchronization signals, broadcast and paging messages as these signals are still transmitted by aggressor cell even during ABS. These signals and messages were necessary even during ABS in order to ensure backward compatibility with Release-8/9 UEs.

The major issue with eICIC is that, in CRE region the interference from CRS of aggressor cell (even during ABS). This makes demodulation of data (PDSH) and control channels/signals (PSS/SSS, PBCH, CRS) from victim cell (pico cell) very difficult.

ICIC is evolved in LTE 3GPP Release-11 to Further enhanced ICIC (FeICIC). The focus here is interference handling by the UE through inter-cell interference cancellation. With FeICIC the cell expansion is spread even further by increasing the biasing level from approximately 6dB to more than 9dB. Increase in bias, further extends small cell’s CRE therefore HetNet efficiency is improved.

FeICIC is mainly implemented at the UE side. The UE’s receiver first estimates the interfering signal and then removes/subtracts the interference from the received signal. In order for the UE’s receiver to apply interference cancellation, the UE needs to be assisted by the serving eNB with some information pertaining to the aggressor cell. For each interfering cell, the following CRS assistance information is signalled to the UE.

-   Physical Cell ID
-   Number of Antenna ports
-   MBSFN subframe configuration

With the help of CRS assistance information for each interfering cell, the UE can determine the location and the sequence of interfering CRS. MBSFN configuration is also important as there is no CRS transmitted in the data region in MBSFN subframes.

Furthermore, the UE may use CRS assistance information to mitigate CRS interference while performing RRM/RLM/CSI measurements. These measurements are discussed in detail in eICIC post.

RRC signaling support
In Release-11, a couple of new UE capabilities (shown below) are introduced to inform the eNB that the UE is capable of performing interference cancellation.


The UE’s support of interference handling for CRS is indicated by the parameter crs-InterfHandl whereas ss-CCH-InterfHandl indicates support for synchronization signal and common channel interference handling.

As discussed already, the eNB may send CRS assistance information of the aggressor cells to the UE to aid the UE to mitigate the interference from CRS of the aggressor cells. In Release-11, RadioResourceConfigDedicated may optionally include neighCellsCRS-Info-r11 which is used to send CRS assistance information of one or several aggressor cells as shown in the figure below.


SIB1 via dedicated RRC signalling
With FeICIC, the UE in CRE with 9dB bias, it is expected that the UE may not be able to decode SIB1 as the interference from aggressor cell is very high. One could argue that the interference is equally applicable for MIB, SIB1 and SIB2 which is the most important system information in LTE.

MIB is transmitted on PBCH in subframe#0 of every radio frame (including repetitions) so it encounters a strong interference from aggressor cell’s MIB and other signals. A UE supporting interference cancellation of common channels (UE indicates with ss-CCH-InterfHandl) could easily mitigate this interference problem.

SIB2 and all other SIBs (except SIB1) are scheduled within periodically occurring SI-windows using dynamic scheduling. So, the serving cell can easily schedule these SIBs in protected subframes (aggressor cell’s ABS).

SIB1 uses a fixed schedule. SIB1 and its repetitions are usually transmitted on PDSCH in subframe#5 of a radio frame for which SFN mod 2 = 0 (even radio frames). It is really difficult to avoid or cancel the interference when the subframe overlaps with a non-protected subframe. For this reason, in Release-11, the eNB may provide SIB1 to the UE in the CRE region by a dedicated RRC signaling. A new IE (shown below) systemInformationBlockType1Dedicated-r11 is introduced for this purpose.



Reference: 3GPP TS 36.300, 36.331, 36.101, 36.133, HetNet

LTE: Connected Mode DRX

In LTE, without Discontinuous Reception (DRX), the UE has to be awake all the time in order to decode downlink data, as the data in the downlink may arrive at any time. This means that UE has to be monitoring PDCCH in every subframe in order to check if there is downlink data available. This consumes a lot of the user equipment’s power
DRX in LTE is introduced to improve UE battery lifetime. In DRX, UE discontinuously receives PDCCH. This post discusses LTE Connected mode DRX.
The eNodeB configures DRX with a set of DRX parameters. These DRX parameters are selected based on the application type such that power and resource savings are maximized.
When DRX is enabled, there may be an extended delay in receiving data as, the UE may be in DRX Sleep state at the time of data arrival at the eNodeB, and the eNodeB would have to wait until the UE becomes ON. So the DRX parameters have to be carefully selected such that the packet delay is minimized and power saving is maximized.
During DRX mode, the UE powers down most of its circuitry when there are no packets to be received. During this time UE listens to the downlink (DL) occasionally which is called DRX Active state whereas the time during which UE doesn’t listen PDCCH is called DRX Sleep state
DRX is also beneficial to the eNodeB. Without DRX, the UE would be transmitting periodic CSI or SRS very frequently (based on the configuration). With DRX, during OFF periods, the UE is not allowed to transmit Periodic CSI or SRS, so the eNodeB can assign these resources to the other UEs to maximize resource utilization.

DRX Configuration
The eNodeB configures the following RRC parameters for DRX. Entire DRX configuration is sent under drx-config structure under MAC-MainConfig. Each DRX parameter and its’ purpose is explained below
In RRC specification, almost all the DRX timer values are specified in terms of psfs. psf is a PDCCH subframe in which UE listens for PDCCH. In FDD every subframe is a DL/UL subframe so every subframe can be a psf whereas in TDD, only DL subframes are considered to be psfs.
  • drx-Inactivity-Timer specifies the number of consecutive PDCCH-subframe(s) for which the UE should be Active after successfully decoding a PDCCH indicating a new transmission (UL or DL) . This timer is restarted upon receiving PDCCH for a new transmission (UL or DL). Upon the expiry of this timer the UE should go to DRX mode.
  • shortDRX-Cycle is the first type of DRX cycle (if configured) that needs to be followed when UE enters DRX mode. This IE indicates the length of the short cycle in subframes which include ON time followed by a possible OFF (inactivity) time.
  • drxShortCycleTimer expressed as multiples of shortDRX-Cycle. The timer value can vary from 1 to 16 (short DRX cycles). This timer indicates the number of initial DRX cycles to follow the short DRX cycle before entering the long DRX cycle
  • longDRX-CycleStartOffset defines long DRX cycle length as well as the DRX offset. DRX offset is used to calculate the starting subframe number for DRX cycle.
  • onDurationTimer specifies the number of consecutive PDCCH-subframe(s) at the beginning of each DRX Cycle (DRX ON). i.e., is the number of subframes over which the UE shall read PDCCH during every DRX cycle before entering the power saving mode (DRX OFF)
  • HARQ RTT Timer specifies the minimum amount of subframe(s) duration from the time new transmission is received and before the UE can expect a retransmission of the same packet. This timer is fixed and not configured by RRC. For FDD the HARQ RTT Timer is set to 8 subframes. For TDD the HARQ RTT Timer is set to k + 4 subframes, where k is the interval between the downlink transmission and the transmission of associated HARQ feedback
  • drx-RetransmissionTimer indicates the maximum number of subframes for which UE should be monitoring PDCCH when a retransmission from the eNodeB is expected by the UE.

Same onDurationTimer value is applied for both long and short DRX cycles
If shortDRX-Cycle is configured, the value of longDRX-Cycle shall be a multiple of the shortDRX-Cycle value
UE indicates the support of Short DRX cycle in featureGroupIndicators bit- 4
UE indicates the support of Long DRX cycle and DRX command MAC control element (together) in featureGroupIndicators bit – 5

DRX Command MAC Control Element
We have seen that a number of timers which controls the UE’s DRX state (ON/OFF). In addition to these timers the eNodeB’s MAC can also control UE’s DRX behavior by transmitting a command called DRX Command as a MAC Control Element.
When the eNodeB doesn’t have any (more) data to be sent to the UE, it can transmit DRX Command MAC CE to the UE. Upon reception of DRX Command MAC CE, the UE enters short DRX cycle if configured, otherwise, the UE enters long DRX cycle.
In reality, DRX Command MAC CE shortens UE’s ON period. For example, if DRX Command MAC CE is received when either onDurationTimer or drx-Inactivity-Timer running, the UE stops the timer and enters into DRX cycle (Short/Long)
The DRX Command MAC control element is identified by a MAC PDU subheader with LCID as 11110. It has a fixed size of zero bits.

DRX Active Time
Active Time is the time during which the UE is considered to be monitoring PDCCH. The Active Time includes the time while:
onDurationTimer is running;
drx-InactivityTimer is running;
drx-RetransmissionTimer is running:
As an example, let us say that the UE has received new data in subframe #n on PDSCH. The UE starts HARQ RTT Timer in the same subframe #n. Upon the expiry of HARQ RTT timer, if the data for the corresponding HARQ process was not successfully decoded (CRC error) then the UE starts drx-RetransmissionTimer for the corresponding HARQ process. The UE needs to be monitoring PDCCH while this timer is running as the retransmission can be expected by the UE during this time.
mac-ContentionResolutionTimer is running:
The UE shall start mac-ContentionResolutionTimer from the next subframe after transmitting Msg3. Since the UE is waiting for the contention resolution which is via PDCCH reception on C-RNTI (in connected mode), the UE needs to be monitoring PDCCH. So the time duration in which mac-ContentionResolutionTimer is running is also considered as Active Time
Scheduling Request has been sent on PUCCH and is pending:
The UE has to be in active state from the next subframe after transmitting SR over the air on PUCCH. After transmitting SR, the UE should be DRX active in order to receive grant from the eNodeB
An uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer:
Let us say that the DCI0 for initial transmission is received at subframe #n, the UE shall become active at subframes n+8, n+16, n+24...n+(maxHARQTx-1)*8 for a possible retransmission
A PDCCH indicating a new transmission addressed to the C-RNTI of the UE has not been received after successful reception of a RAR for the preamble not selected by the UE
In the non-contention based RA, after receiving RAR, the UE should be in active state until PDCCH indicating new transmission addressed to C-RNTI of the UE is received

DRX Operation
When there is no data activity for drx-InactivityTimer amount of time (i.e., upon expiry of drx-InactivityTimer) or DRX Command MAC CE is received,
-  if the Short DRX cycle is configured, then the UE should  start or restart drxShortCycleTimer and start using Short DRX Cycle. Else if Short DRX cycle is not confired, the UE should use the Long DRX cycle
If drxShortCycleTimer expires, i.e., maximum number of short cycles are already used, then the UE should enter the Long DRX cycle
If a DRX Command MAC control element is received, the UE should stop onDurationTimer and drx-InactivityTimer
During the active time, the UE shall monitor the PDCCH; if the PDCCH indicates a new transmission (DL or UL) in subframe #n, then the UE should start/restart drx-InactivityTimer in subframe #n+1
The UE should start onDurationTimer in a subframe which satisfies the following equation (based on whether short DRX cycle is configured or not):
If the Short DRX Cycle is used,
[(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)
else if the Long DRX Cycle is used
[(SFN * 10) + subframe number] modulo (longDRX-Cycle ) =  drxStartOffset
When downlink assignment has been configured (DL SPS), and if the configured assignment recurs in subframe that does not fall in Active time, the UE need not decode PDSCH. It is the eNodeB’s responsibility to make sure that the configured assignment falls in onDurationTimer
During RAR-window, if a subframe falls in non-Active time, then the UE monitors PDCCH only for RA-RNTI
Regardless of whether the UE is monitoring PDCCH or not, the UE receives and transmits HARQ feedback when such is expected.
When more than one serving cell is configured (CA), the same active time applies to all activated serving cell(s). For FDD, The UE maintains a set of 8 HARQ-RTT/drx-RetransmissionTimers for each serving cell. The UE monitors PDCCH on all serving cells, even if the active time corresponds to only one serving cell

Periodic CSI on PUCCH and SRS in DRX mode
When not in Active time, the UE shall not transmit periodic SRS (type-0 triggered SRS)
A release-8 UE shall not transmit periodic CSI on PUCCH when not in Active time.
In release-9, CQI-mask IE is introduced which limits CQI/PMI/PTI/RI reports to the on duration period of the DRX cycle. If the IE CQI-mask is not setup by RRC, CQI/PMI/RI/PTI on PUCCH shall not be reported when not in Active time; else UE should send CQI/PMI/RI/PTI on PUCCH only if onDurationTimer is running

When more than one serving cell is configured (CA), one value of cqi-Mask applies for all serving cells (the associated functionality is common i.e. not performed independently for each cell)


Reference: 3GPP TS 36.321, 36.213, 36.331
DRX calculations

Long DRX-cycle           Offset          onDurationTimer           Short DRX-cycle
                                                    

                                                                                              UL-DL Config
        Is Short DRX?         Is TDD?         

Long DRX Occasions
Long DRX Occasions will be displayed here


Short DRX Occasions
Short DRX Occasions will be displayed here


LTE: System Information Block Type 7

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

The SystemInformationBlockType7 (SIB7) contains inter-RAT cell re-selection information only for GERAN. It includes cell re-selection parameters for each frequency. SIB7 also contains cell reselection priority information 

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType7 message

LTE: System Information Block Type 6

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

The SystemInformationBlockType6 (SIB6) contains information relevant only for inter-RAT cell re-selection i.e. information about UTRA frequencies and UTRA neighbouring cells relevant for cell re-selection. It includes cell re-selection parameters which are common for an UTRA frequency.

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType6 message

LTE: System Information Block Type 5

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

The SystemInformationBlockType5 (SIB5) contains neighbor cell related information for inter-frequency cell-reselection i.e. the information about neighbor E-UTRA frequencies

SIB5 includes neighbor cell list, carrier frequency, cell reselection priority, threshold used by the UE when reselecting a higher/lower priority frequency than the current serving frequency etc. It also contains a list of blacklisted inter-frequency neighbouring cells

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType5 message

LTE: System Information Block Type 4

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

The SystemInformationBlockType4 (SIB4) contains intra-frequency neighboring cell information for intra-LTE intra-frequency cell reselection, such as neighbor cell list, and black listed Cell list

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType4 message

LTE: System Information Block Type 3

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

The SystemInformationBlockType3 (SIB3) contains cell re-selection information common for intra-frequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all)

SIB3 also contains cell reselection priority information for the concerned carrier frequency or a set of frequencies

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType3 message

LTE: System Information Block Type 2


Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

SystemInformationBlockType2 (SIB2) contains radio resource configuration information that is common for all UEs. It contains access barring information, radio resource configuration of common and shared channels, timers and constants which are used by UEs, uplink power control information etc.

SIB2 is not specifically included in the scheduling information in SIB1 but it is always mapped to the SI message that corresponds to the first entry in the list of SI messages in schedulingInfoList in SIB1

SIB2 also gives information about the uplink carrier frequency and the uplink channel bandwidth in terms of number of Resource Blocks

Some of the IEs in SystemInformationBlockType2:

UL-CarrierFreq: If this IE is absent (for FDD), the UL-Carrier Frequency value should be determined from the default TX-RX frequency separation defined in TS 36.101 [Table 5.7.3-1]. For TDD, this parameter is absent and it is equal to the downlink frequency
UL-Bandwidth: Transmission bandwidth configuration, NRB, in uplink. The value n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on. If this parameter is absent for FDD then the uplink bandwidth is equal to the downlink bandwidth. For TDD this parameter is absent and it is equal to the downlink bandwidth
defaultPagingCycle: Default paging cycle value rf32 corresponds to 32 radio frames, rf64 corresponds to 64 radio frames and so on
modificationPeriodCoeff: Actual modification period, expressed in number of radio frames= modificationPeriodCoeff * defaultPagingCycle.The value n2 corresponds to value 2, n4 corresponds to value 4, and so on
p-Max: Maximum power to be used in the target cell. If this IE is absent then the UE applies the maximum power according to the UE capability
UL-CyclicPrefixLength: The value len1 corresponds to normal cyclic prefix and len2 corresponds to extended cyclic prefix
RadioResourceConfigCommonSIB: The IE RadioResourceConfigCommonSIB is used to specify common radio resource configurations e.g., the random access parameters and the static physical layer parameters

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType2 message

LTE: System Information Block Type 1

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: DL-SCH

SystemInformationBlockType1 (SIB1) contains information relevant when evaluating if a UE is allowed to access a cell. Also, it supplies the UE with the scheduling of other system information. SIBs other than SIB1 are carried in SystemInformation (SI) messages and mapping of SIBs to SI messages is flexibly configurable by schedulingInfoList included in SIB1

SIB1 uses a fixed schedule with a periodicity of 80ms and repetitions made within 80ms. The first transmission of SIB1 is scheduled in subframe #5 of radio frames for which the SFNmod8 = 0, and repetitions are scheduled in subframe #5 of all other radio frames for which SFNmod2 = 0

SIB1 contains cell access related information (e.g. a PLMN identity list, tracking area code, cell identity, etc.), information for cell selection (e.g. minimum required Rx level in the cell and offset), p-Max, frequency band indicator, scheduling information, TDD configuration, SI-window length and system information value tag etc...

Upon receiving the SIB1 message the UE shall check the IE freqBandIndicator. The UE shall consider the cell as barred if the frequency band indicated in the freqBandIndicator is not part of the frequency bands supported by the UE

Some of the IEs in SystemInformationBlockType1 message:
PLMN-IdentityList: List of PLMN identities. The first listed PLMN-Identity is the primary PLMN
TrackingAreaCode: A trackingAreaCode that is common for all the PLMNs listed
Cellidentity: Identity of the cell
CellBarred: 'barred’ means the cell is barred
IntraFreqReselection: Used to control cell reselection to intra-frequency cells when the highest ranked cell is barred, or treated as barred by the UE
CSG-Indication: If this IE is set to TRUE the UE is only allowed to access the cell if the CSG identity matches an entry in the CSG whitelist that the UE has stored
p-Max: Maximum power value applicable for the cell. If this IE is absent, then the UE applies the maximum power according to the UE capability
freqBandIndicator: Operating frequency band of the cell as defined in TS 36.101 [Table 5.5-1].
si-Periodicity: Periodicity of the SI-message in radio frames, such that rf8 denotes 8 radio frames, rf16 denotes 16 radio frames, and so on
sib-MappingInfo: List of the SIBs mapped to this SystemInformation message. There is no mapping information of SIB2; it is always present in the first SystemInformation message listed in the schedulingInfoList list.
si-WindowLength: Common SI scheduling window for all SIs. Unit in milliseconds, where ms1 denotes 1 millisecond, ms2 denotes 2 milliseconds and so on
systemInfoValueTag: Common for all SIBs other than MIB, SIB1, SIB10, SIB11 and SIB12. Change of MIB and SIB1 is detected by acquisition of the corresponding message
csg-Identity: Identity of the Closed Subscriber Group within the primary PLMN the cell belongs to. This field is present in a CSG cell
ims-EmergencySupport: Indicates whether the cell supports IMS emergency bearer services for UEs in limited service mode. If absent, IMS emergency call is not supported by the network in the cell for UEs in limited service mode

Reference: 3GPP TS 36.331

Example: SystemInformationBlockType1 message

LTE: Master Information Block

Direction: E-UTRAN => UE
Signalling Radio Bearer: N/A
RLC Mode: TM
Logical Channel: BCCH
Transport Channel: BCH

The MASTER INFORMATION BLOCK (MIB) includes a limited number of most essential and most frequently transmitted parameters that are needed to acquire other information from the cell. The MIB is transmitted on BCH while all other SYSTEM INFORMATION messages are transmitted on DL-SCH

As MIB is the most important information block, it is transmitted more frequently with a fixed scheduling. The MIB uses a periodicity of 40ms and repetitions made within 40ms. The first transmission of the MIB is scheduled in subframe #0 of radio frames for which the SFNmod4 = 0, and repetitions are scheduled in subframe #0 of all other radio frames

The MIB contains DL bandwidth of the cell, PHICH configuration and the System Frame Number (SFN)

IEs in the MASTER INFORMATION BLOCK message
dl-Bandwidth: Transmission bandwidth configuration, nRB in downlink. The value n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on. Possible values are n6, n15, n25, n50, n75, and n100. Table1 below gives the corresponding mapping to the actual channel bandwidth (Reference: 3GPP TS 36.101)
systemFrameNumber: Defines the 8 most significant bits of the SFN
phich-Config: This IE is used to specify the PHICH configuration


Table1: Transmission bandwidth configuration NRB in E-UTRA channel bandwidths







Example: MASTER INFORMATION BLOCK message