3G Evolution. HSPA and LTE for Mobile Broadband

possibility to set UE-specific offsets to spread the DPCCH transmission occasions from different UEs in time.

To adapt the UE DTX cycle to the traffic properties, two different cycles are defined, UE DTX cycle 1 and UE DTX cycle 2, where the latter is an integer multiple of the former. After a certain configurable period of inactivity on the E-DCH, the UE switches from UE DTX cycle 1 to UE DTX cycle 2, which has less frequent DPCCH transmission instants.

Discontinuous reception in the NodeB is possible thanks to the use of uplink DTX and can be useful to save processing resources in the NodeB as it does not have to continuously process the received signal from all users. To enable this possibility, the network can configure the UE to allow E-DCH transmissions to start only in certain (sub)frames. A certain time after the last E-DCH transmission, the restriction takes effect and the UE can only transmit in the uplink according to the MAC DTX Cycle.

During slots where the DPCCH is not transmitted, the NodeB cannot estimate the uplink signal-to-interference ratio for power-control purposes and there is no reason for transmitting a power control bit in the downlink. Consequently, the UE shall not receive any power control commands on the F-DPCH in downlink slots corresponding to inactive uplink DPCCH slots. For improved channel-estimation performance and more accurate power control, preambles and postambles are used. For UE DTX cycle 1, the UE starts DPCCH transmission two slots prior to the start of E-DPDCH, as well as ends the DPCCH transmission one slot after the E-DPDCH transmission. This can be seen in Figure 12.6. For UE DTX cycle 2, the preamble can be extended to 15 slots. The preamble and postamble is used also for the DPCCH bursts due to data transmission as well as any HS-DPCCH transmission activity as discussed below.

Until now, the discussion has concerned user-data transmission on the E-DCH and not the control signaling on the HS-DPCCH, which also represents a certain overhead. With CPC enabled, the hybrid ARQ operation remains unchanged and the UE transmits a hybrid ARQ acknowledgment after each HS-DSCH reception, regardless of the UE DTX cycle. Clearly, this is sensible as ACK/NAK signaling is important for the HS-DSCH performance. It also does not conflict with the possibilities for NodeB discontinuous reception as the NodeB knows when to expect any acknowledgments.

For the CQI reports, the transmission of those reports depends on whether there has been a recent HS-DSCH transmission or not. If any HS-DSCH transmission has been directed to the UE within at most CQI DTX Timer subframes, where CQI DTX Timer is configured via RRC signaling, the CQI reports are transmitted

Figure 12.7 CQI reporting in combination with uplink DTX.

according to the configured CQI feedback cycle in the same way as in Release 5 and 6. However, if there has not been any recent HS-DSCH transmission, CQI reports are only transmitted if they coincide with the DPCCH bursts. Expressed differently, the uplink DTX pattern overrides the CQI reporting pattern in this case (Figure 12.7).

12.3.2DRX – reducing UE power consumption

In ‘normal’ HSDPA operation, the UE is required to monitor up to four HS-SCCHs in each subframe. Although this allows for full scheduling flexibility, it also requires the UE to continuously have its receiver circuitry switched on, leading to a non-negligible power consumption. Therefore, to reduce the power consumption, CPC introduces the possibility for Downlink Discontinuous Reception (downlink DRX). With discontinuous reception, which always is used in combination with discontinuous transmission, the network can restrict in which subframes the UE shall monitor the downlink HS-SCCH, E-AGCH, and E-RGCH by configuring a UE DRX cycle to be used after a certain period of HS-DSCH inactivity. Note that, in this case, the UE can only be scheduled in a subset of all the subframes, which limits the scheduling flexibility somewhat, but for many services such as VoIP with regular packet arrival approximately once per 20 ms, this is not a major problem.

The E-HICH is not subject to DRX as this obviously would not make sense. Hence, whenever the UE has transmitted data in the uplink, it shall monitor the E-HICH in the corresponding downlink subframe to receive the acknowledgment (or negative acknowledgment).

For proper power-control operation, the UE needs to receive the power control bits on the F-DPCH in all downlink slots corresponding to uplink slots where the UE does transmit. This holds, regardless of any UE DRX cycle in the downlink. Therefore, to fully benefit from downlink DRX operation, the network should use uplink DTX in combination with downlink DRX and configure the UE DTX and

Switch to UE DTX cycle 2

E-DCH activity

DPCCH

UE DRX cycle

Downlink channels

Figure 12.8 Example of simultaneous use of uplink DTX and downlink DRX.

UE DRX cycles to match each other. An example of simultaneous use of DTX and DRX is shown in Figure 12.8.

12.3.3HS-SCCH-less operation: downlink overhead reduction

In the downlink, each user represents a certain overhead for the network in terms of code usage and transmission power. The fractional DPCH, F-DPCH, introduced already in Release 6 addresses this issue by significantly reducing the channelization code space overhead. Another source of overhead is the HS-SCCH, used for downlink scheduling. In case of medium-to-large payloads on the HS-DSCH, the HS-SCCH overhead is small relative to the payload; however, for services such as VoIP with frequent transmissions of small payloads, the overhead compared to the actual payload may not be insignificant. Therefore, to address this issue and increase the capacity for VoIP, the possibility for HS-SCCH-less operation is introduced in Release 7. The basic idea with HS-SCCH-less operation is to perform HS-DSCH transmissions without any accompanying HS-SCCH. As the UE in this case is not informed about the transmission format, it has to revert to blind decoding of the transport format used on the HS-DSCH.

When HS-SCCH-less operation is enabled, the network configures a set of predefined formats that can be used on the HS-DSCH. To limit the complexity of the blind detections in the UE, the number of formats is limited to four and all formats are limited to QPSK and at most two channelization codes. This is well matched to the small transport-block sizes, in the order of a few hundred bits, for which HS-SCCH-less operation is intended. Furthermore, the UE knows which channelization code(s) that may be used for HS-SCCH-less transmission.

In each subframe where the UE has not received any HS-SCCH control signaling, the UE tries to decode the signal received according to each of the preconfigured formats. If decoding of one of the formats is successful, the UE transmits an ACK

on the HS-DPCCH and delivers the transport block to higher layers. If the decoding was not successful, the UE stores the received soft bits in a soft buffer for potential later retransmissions. Note that no explicit NAK is transmitted in this case. Clearly, this would not be possible as the UE does not know whether the unsuccessful decoding was the result of the UE being addressed, but the transmission received in error, or the UE not being addressed at all. In ‘normal’ operation, these two cases can be differentiated as there is an HS-SCCH transmission detected in the former but not in the latter case, but in HS-SCCH-less operation this is obviously not possible.

Normally, the HS-SCCH carries the identity of the UE being scheduled. However, in case of HS-SCCH-less operation, this is obviously not possible and the identity of the scheduled UE must be conveyed elsewhere. This is solved by masking the 24-bit CRC on the HS-DSCH with the UE ID using the same general procedure as for the HS-SCCH. Since the UE knows its identity, it can take this into account when checking the CRC and will thus discard transmissions intended for other UEs.

It is possible to mix HS-SCCH-less operation with ‘normal’ transmissions. If the UE receives the HS-SCCH in a subframe for an initial transmission, it obeys the HS-SCCH and does not try to perform blind decoding. Only if no HS-SCCH directed to this UE is detected will the UE attempt to blindly decode the data. For backward compatibility reasons the same procedure as in previous releases is used for CRC attachment; only for HS-SCCH-less operation is the HS-DSCH CRC masked with the UE ID.

Unlike the initial transmissions discussed so far, hybrid ARQ retransmissions are accompanied with an HS-SCCH. The HS-SCCH is transmitted using the same structure as for normal HS-DSCH transmissions; however, the bits are reinterpreted to provide the UE with:

•an indication that this is a retransmission of a previous HS-SCCH-less transmission;

•whether it is the first or second retransmission;

•the channelization code set and transport-block size;

•a pointer to the previous transmission attempt the retransmission should be soft combined with.

The reason for this information is to guide the UE in how to perform soft combining; if this information would not have been provided to the UE, the UE would have been forced to blindly try different soft combining strategies and take a hit in complexity. Furthermore, to reduce complexity, at most two retransmissions are supported and the redundancy version to use for each of them is preconfigured.

To be able to perform soft combining, the UE needs to store the soft bits from the previous attempts. With a maximum of three transmissions, one initial and

state (known as CELL_DCH in WCDMA) while still providing mechanisms for reduced power consumption. However, eventually the UE will be switched to CELL_FACH if there has been no transmission activity for a certain period of time. Once the UE is in to CELL_FACH, signaling on the Forward Access Channel (FACH), a low-rate common downlink transport channel, is required to move the UE to CELL_DCH prior to any data exchange on HS-DSCH and E-DCH can take place. The physical resources to which the FACH is mapped is semi-statically configured by the RNC and, to maximize the resources available for HS-DSCH and other downlink channels, the amount of resources (and thus the FACH data rate) is typically kept small, in the order of a few tens of kbit/s.

To reduce the latency associated with state changes, Release 7 improves the performance by allowing HS-DSCH to be used also in the CELL_FACH state. This is often referred to as Enhanced CELL_FACH operation. Using the HS-DSCH also in CELL_FACH allows for a significant reduction in the delays associated with switching to CELL_DCH state. Instead of using a low-rate FACH, the signaling from the network to the UE can be carried on the high-rate HS-DSCH. This can result in a significant reduction in call-setup delay and a corresponding improvement in the user perception.

In enhanced CELL_FACH operation, the UE monitors the HS-SCCH for scheduling information using the same principles as described in Chapter 9. However, one major difference compared to the HS-DSCH procedures described in Chapter 9 is that no dedicated uplink is present in the CELL_FACH state. Consequently, no CQI reports are available for rate adaptation and channel-dependent scheduling, nor is it possible to transmit any hybrid ARQ feedback. Therefore, rate adaptation and channel-dependent scheduling has to be based on long-term measurements, transmitted as part of the random-access procedure used to initiate the state change. To account for the lack of hybrid-ARQ feedback, the network can blindly retransmit the downlink data a preconfigured number of times to ensure reliable reception at the UE.

If the same MAC header format as described in Section 12.5 below is used, it is even possible to start transmitting user data to the mobile terminal while carrying out the switch from CELL_FACH to CELL_DCH. This result in a significant improvement in the user perception compared to the approach used prior to Release 7, where data transmission is suspended during the state change.

Furthermore, HS-DSCH reception is also supported in the paging states. This allows for rapid switching also from the paging states and is similar to the approach taken by LTE for paging as described in Chapter 17.

12.5Layer 2 protocol enhancements

To fully benefit from the high data rates supported by HS-DSCH, especially in combination with 64QAM and MIMO, Release 7 introduces enhancements to the RLC and MAC-hs protocols in additions to the physical-layer enhancements. In releases prior to Release 7, the RLC PDU size is semi-statically configured. This is appropriate for the low-to-medium data rates, but for the high data rates targeted by HSPA Evolution, the RLC PDU size, the RLC roundtrip time, and the RLC window size may limit the peak data rates and cause the RLC protocol to stall [55]. One possibility to avoid this is to increase the RLC PDU size, but for Release 7 a somewhat more advanced solution has been adopted, flexible RLC. The flexible RLC is based on ideas such as those in [18].

Segmentation of RLC PDUs into smaller MAC PDUs, matched to the instantaneous radio conditions, is introduced. This allows the RLC size to be sufficiently large to keep the overhead from RLC headers small while at the same time keeping the padding overhead modest. It would appear natural that RLC directly creates RLC PDUs with a size adapted to the radio conditions. This is also the approach taken by the RLC in LTE as described in Chapter 15 where the RLC and the scheduler are located in the same node. For HSPA, the situation is different. Since the RLC and the scheduler in this case are loacated in the RNC and NodeB, respectively, and the instantaneous radio conditions are not known to the RNC, this is not possible for HSPA. However, segmenting the RLC PDUs into smaller MAC PDUs in the NodeB, where the size depends on the instantaneous radio conditions, is a good approximation to fully adaptive RLC PDU sizes.

Furthermore, RLC SDUs are segmented if the SDU size exceeds a certain limit. This increases the RLC retransmission efficiency in case the MAC hybrid-ARQ mechanism fails, triggering an RLC retransmission.

The restriction of not allowing multiplexing data from different radio bearers into the same transport block is also removed in Release 7. This increases the resource efficiency for mixed-service scenarios.

12.6Advanced receivers

There are many ways to enhance performance in terms of, for example, data throughput and coverage without modifications to the specifications. Many of these enhancements are based on more advanced receiver algorithms and are thus implemented in software in the baseband processing. Other enhancements require more ‘hardware’ in terms of antennas and RF components, for example, receiver antenna diversity and beam-forming techniques. Advanced receivers are possible for both base stations and mobile devices (UEs).

For the single receiver, the enhancement is manifested by a decrease in the signal- to-noise ratio (Eb/N0) required for a specific quality of service. The improved receiver performance enables improved quality of service in terms of, for example, end-user data rates. If a large number of the user devices have receiver enhancements, it will lead to improved system performance in terms of, for example, system wide data throughput.

The standards developed in 3GPP do in principle not specify the receiver structure to be used. The specifications define performance requirements for demodulation of the different physical channels. What type of receiver implementation that is used to meet those requirements is not specified, there is full freedom for a UE vendor to use any implementation, as long as the 3GPP requirements are met.

It is for this reason not possible to mandate use of certain receivers through the 3GPP specifications, if the freedom of implementation is to be kept. Most performance requirements are however developed with a baseline receiver in mind. The performance of the baseline receiver is simulated and an agreed ‘implementation margin’ is added to the results to model (additional) receiver imperfections not included in the simulations. Once the agreed performance limit is entered into the specification, it is to be fulfilled regardless of what receiver has been implemented.

12.6.1Advanced UE receivers specified in 3GPP

The typical receiver for CDMA is the so-called RAKE receiver [50]. It assumes that noise is uncorrelated between the so-called RAKE taps that independently demodulate propagation components received with different delays.

As described above, the advanced receivers are not specified and mandated as such in the 3GPP specifications. Instead there are multiple ‘types’ of requirements defined, each based on a different baseline receiver. The UE vendor declares which type of requirements that the UE conforms to. There are three types of enhanced receiver-performance requirements defined in 3GPP specifications, see [92]; see also Table 12.3. Each type of requirement below is optional:

1.Type 1: Performance requirements which are based on UEs utilizing receiver diversity.

2.Type 2: Performance requirements which are based on UEs utilizing a Linear Minimum Mean Square Error (LMMSE) chip-level equalizer receiver structure.

3.Type 3: Performance requirements which are based on UEs utilizing both receiver diversity and a chip-level equalizer structure.