Archive for the ‘Technical Notes’ Category

Payload Header Suppression (PHS) is an optional feature in 802.16-2004. Since the bandwidth on the air interface is limited and shared by multiple users within a sector, it makes sense to optimize the use of such bandwidth. The idea of PHS is to remove redundant information in packet headers using known rules. These suppression rules help in reconstructing the header correctly at the receiving end. The rules are agreed in advance between SS and BS. In general, these rules are designed in such a way that fields of the header that do not change for the entire duration of the service flow are suppressed. Only changing fields are transmitted. Since the standard allows for multiple rules for every service flow,

The following important points are made about PHS:

  1. PHS rules are specific to service flows. Thus, a rule agreed for a service flow cannot be applied to another service flow.
  2. Every service flow can have multiple rules with one rule per classifier. Each rule is referenced using an index named PHSI. A classifier is associated with a rule using the PHSI. While the rule for a service flow can be changed, the new rule must be added to the service flow only after deleting the old rule. During this transition when no rule is defined, PHSI=0 will not be used.
  3. PHSI will be omitted if PHS is not enabled. “Not enabled” is taken to mean that PHS rule is not defined.
  4. The use of PHSI=0 preceding a higher layer PDU implies that suppression has not been applied for this PDU though PHS is enabled for this service flow.
  5. Some service flows can have PHS enabled while others may wish to disable it.
  6. When PHS is enabled, option exists to enable verification procedures at the transmitting end. Essentially, this CS layer verifies that higher layers have not changed the values of fields that have been identified for suppression.
  7. While rules can be defined at either end (BS or SS), only the BS can allocated a PHSI.
  8. In general, the responsibility to generate a rule lies with the higher layer (or manually configured using NMS). It is not part of the Convergence Sublayer (CS). This makes good sense for layered design. Nonetheless, intelligence can be built into CS for reasons described later in this document.
  9. Rules can be created in a single message flow or in separate message flows. Typically, one could create a rule at provisioning based on certain known header fields. This could be altered later at service activation in order to achieve greater suppression.
  10. Rule creation can happen as part of the creation of service flow and its classifier. It can also happen in a separate message flow.
  11. Rule creation can use DSA or DSC messages.
  12. Rule deletion can use DSC or DSD messages.
  13. It is possible to delete a PHS rule, delete all rules, add a rule or set a rule. When deleting all rules, PHSI will be ignored. Add a rule that already exists is an error.
  14. PHS rule consists of the following set – {PHSI, PHSF, PHSM, PHSS, PHSV, Vendor-specific PHS parameters}.
  15. If there is any error in rule definition as part of DSA or DSC, the receiver should ignore the message. There is no mechanism in the standard to inform sender the source of error.
  16. Since PHS happens before encryption, the latter has no effect on PHS. In other words, PHSF is constructed based on unencrypted data.

At a high level, enabling PHS is signaled as part of REG-REQ. This indicates capability of SS. PHS will be possible only if both BS and SS are able to support it and agree to use it after negotiation.

A brief summary of all parameters of a PHS rule follows.


This is unique per service flow. This is used to identity the PHS rule. It precedes the higher layer PDU when PHS is enabled. It does not exist when PHS is disabled. If PHS is enabled and suppression is not done, PHSI=0 is used. It has the range 1-255.


This is a specified number of bytes containing header information to be suppressed. It is stored and used on both sending and receiving sides. Number of bytes is same as the value of PHSS.


This is a mask that determines which parts of the PHSF need to be suppressed. A value of 1 indicates a byte to be suppressed. Otherwise, the byte is included in the transmission. This has a maximum length of 8 bytes to cover the range of PHSS. Bit 0 related to first byte of PHSF. Bit n related to (n+1)th byte of PHSF. If PHSM is omitted, the default is to suppress all bytes of the PHSF.


This indicates the size of the PHSF. Since this is just one byte, only a maximum of 255 bytes can be suppressed. During rule negotiation, if this is omitted or is of value zero, PHS is disabled.


This controls verification which can be enabled or disabled as part of the rule definition. In general, it is desirable to have this enabled. If omitted, verification is enabled by default.

Read Full Post »

Multiplexing at any level is a way of life because there is great deal of sense in doing it. In protocol engineering, people have long realized that packet-switched networks offer much better network capacity utilization than circuit-switched networks. In CS connections, the link or trunk is reserved for the entire duration of the call. Periods of inactivity or less than maximum rate lead to wastage of resources. In PS networks, any unused bandwidth is quickly deallocated and reallocated to users who need them. More importantly, when a single user has activated multiple services, all services could intelligently share the same underlying bandwidth without requiring fully dedicated resources.

Multiplexing is nothing but bringing together different streams of data into a single stream. While there are different types of multiplexing, in this post we are primarily concerned with time multiplexing of data. Multiplexing requires intelligence in terms of scheduling. In other words, when multiple services are waiting to share a single resource, someone has to intelligently schedule them based on priority, buffer occupancy, power, interference and other such factors.

In this post, I will look at multiplexing done at MAC for R99 transport channels, Rel5 HSDPA and Rel6 HSUPA. Simplifying the whole architecture, it is sufficient to note that for R99, independent data streams are carried in logical channels. There may be some dependence between logical channels that arrive from the same application (such as NB-AMR) but this does not matter to MAC where multiplexing is done. MAC would have been configured appropriately to handle these dependent streams in parallel. These logical channels are multiplexed to transport channels. Once configured, a logical channel can be carried on only one transport channel unless RRC remaps it to a different transport channel. Multiple transport channels exist at the same time. These are again time-multiplexed on the CCTrCh. Thus for R99, MAC multiplexing happens on two levels.

MAC decides what to multiplex for a given TTI. However, it has to obey the constraint set by the TFCS. The TFCS details the set of multiplexing possibilities. This set is formed based on the underlying physical layer capability to transmit data and the average bit rate promised for a given service.

Figure 1: Logical Channel Multiplexing in R99 MAC
R99 Mac Multiplexing

An example of R99 MAC multiplexing is in Figure 1. For this example, the TTIs of TrCh1, TrCh2 and TrCh3 are 10 ms, 10 ms and 20 ms respectively. We can note the following:

  • On any transport channel, only one logical channel can be carried at any one time. Logical channel will be identified in the MAC header.
  • Each logical channel has a PDU size of its own.
  • It is possible that in a given TTI, multiple MAC PDUs can be carried on the same transport channel. This is the case at time (t+20) for TrCh1. Specifications do not require that these PDUs should carry the same logical channel since each transport block has its own C/T field in MAC header to identify the logical channel. However, current specification require that all PDUs within the TTI for a transport channel must be of the same size.
  • It is possible that in some TTIs, nothing is carried for a certain transport channel. This is sensible if all logical channels mapped to the channel have no data to send. This can also happen if there are higher priority logical channels that need the bandwidth. This is the case with TrCh2 at time (t+20).
  • We ought to note that TrCh3 is of TTI 20 ms. We assume for this example that time (t) is on a 20 ms boundary. MAC decides to transmit 2 blocks of data at this time. This is sent on frames starting at (t) and (t+10).
  • Figure 1 is a gross simplification to demonstrate multiplexing at MAC. Actual transmission from PHY happens after many stages of processing that include interleaving, radio frame equalization and radio frame segmentation. The size of MAC header is variable and not fixed as suggested in the figure.
  • Since TrCh2 carries only one logical channel, MAC header will generally not carry any identification for the logical channel. However, MAC header will be still present because it has many other components.

Figure 2: Logical Channel Multiplexing in HSDPA MAC

Let us now turn to HSDPA for which we refer to Figure 2. Let us note the following:

  • There is only one transport channel. Only one transport channel can be carried on the CCTrCh. Although TFCS is defined it is not really a combination as in R99 channels.
  • Control information for multiplexing is embedded within the MAC-hs header while for R99 this control information is in the definition of the TFCS. Because of this, MAC-hs header is highly variable in size.
  • A new concept of MAC-d flow has been introduced for HSDPA. This is mainly used to differentiate traffic on the Iur and Iub. This applies for HSUPA as well.
  • Multiple logical channels can be carried on the same MAC-d flow.
  • A MAC-d flow can be carried on multiple priority queues. In other words, some logical channels of the flow are on one queue while others are on another queue. This is case with Flow 1 and Flow 2 in this example.
  • A priority queue can be used to handle multiple MAC-d flows. This is the case with Q2 in this example.
  • A TTI carries only one transport block. However, the MAC-hs PDU can contain multiple MAC-hs SDUs. The header indicates such multiplexing.
  • MAC-hs PDU can carry MAC-hs SDUs of different sizes. This is unlike R99. Example of this is at time (t+2).
  • A MAC-hs PDU can carry SDUs from only one MAC-d flow and only one priority queue. Thus, although at time (t+2) two different logical channels are carried, they belong to the same MAC-d flow and the same priority queue [TS 25.308, 6.1.4].
  • In R99, C/T field of MAC header is present if logical channels are multiplexed on the same transport channel. In HSDPA, MAC-d uses the same field when multiplexing is done on the same MAC-d flow.
  • Padding is used to fit a transport block size completely.

Figure 3: Logical Channel Multiplexing in HSUPA MAC

E-DCH multiplexing is shown in Figure 3. The following statements can be made of HSUPA MAC multiplexing:

  • Two TTIs are supported: 2 ms and 10 ms. Figure 3 represents the former.
  • As in HSDPA, a TTI can carry only one TB. A CCTrCH can carry only one E-DCH.
  • Multiplexing happens at MAC-e, rather than MAC-es. MAC-es only adds the TSN field in its header. Actual multiplexing information is in MAC-e header.
  • In HSDPA, multiplexing happens at two levels: at MAC-d which may add C/T field to a MAC-d SDU and at MAC-hs. In HSUPA, there is only one level of multiplexing. All of it happens at MAC-e. MAC-es SDU is simply RLC PDU. MAC-d does not add any header. This is because the information in MAC-e header maps directly to a logical channel. This is not the case with MAC-hs header which maps only to the level of a MAC-d flow.
  • Like HSDPA, there is a reordering queue. This is important in the SRNC that does the reordering of MAC-es PDUs. However, in HSUPA, there is one reordering queue for every logical channel. This makes sense because demultiplexing is already done by MAC-e before forwarding data to MAC-es. Reordering queue is not that important at the UE and hence it is not explicitly shown in the figure.
  • Header information is not contiguous. In particular, MAC-e and MAC-es headers are separate.
  • There is an optional padding as in HSDPA to fit a defined TB size. In addition, Scheduling Information (SI) can be sent if there is enough space or if there is a real need to send it.
  • Multiple MAC-d PDUs of a logical channel can be sent in the same MAC-e PDU. However, they should be of the same size.
  • When multiple logical channels are multiplexed, the MAC-d PDU size can be different from one logical channel to another.
  • It is possible for a MAC-e PDU to carry data from different flows [TS 25.209, 7.1.1]. An example of this is at time (t+4).

An additional comment is that a logical channel can carry RLC PDUs of multiple sizes. To my knowledge, NB-AMR Class-A bits is the only one that needs this feature at the moment. Even in this case, it is unlikely that PDUs of different sizes of the same logical channel would need to be sent in the same TTI. This may be one reason why in HSUPA there is a minor constraint on multiplexing as already noted. Otherwise, the design allows great flexibility.

In conclusion, there are significant differences in the three methods of multiplexing discussed above. On the surface they may appear to be similar but when we delve into the details we can appreciate the differences. This also highlights the way specifications have evolved. While R99 provides a layer of multiplexing at CCTrCh, this is no longer used in HSPA. I see this as an improvement because HSPA multiplexing allows for greater flexibility, quicker response and easier implementation. For example, in HSPA we need not do rate matching for multiple transport channels. In R99, if the CCTrCh carries a 80 ms transport channel, the TFCS reduces to a subset until the next 80 ms boundary. This restricts MAC scheduling to a certain extent. To avoid this, a much larger TFCS needs to be signalled at RRC. Blind TFCI TF detection is not applicable to HSPA. Fixed/flexible positioning of transport channels is not applicable either. These extra complications are removed by using a single transport channel per TTI for HSPA.

Read Full Post »

Power Control in HSPA

Last week I wrote about UMTS power control with reference to R99 channels. Today’s post continues the discussion with reference to HSDPA and HSUPA.

Let us begin with HSDPA for which power control is significantly different from R99 channels. HSDPA does not have fast power control as in R99 DL DPCH. However, power control is just as important for HSDPA. Inner loop power control happens implicitly in HSDPA based on Adaptive Modulation and Coding (AMC). This can be understood by acknowledging that WCDMA is an interference limited system. Although reducing power, results in reduced interference this does not have significant impact for users close to the Node-B. Such users do not benefit much by decreasing power nor does system capacity increase. It is known that power control dynamics is only 20 dB in DL and 70 dB in UL [1]. Beyond the 20 dB limit, new techniques such as AMC are more beneficial.

Thus, when users close to the Node-B experience excellent channel conditions, modulation could be changed from QPSK to 16 QAM with an additional increase in coding rate (less redundancy). This increases bandwidth for a given user. Within the cell/sector, fast scheduling (another new feature in HSDPA) enables quick decisions so that one user may be given/denied more resources for relatively short time periods to make the best use of channel conditions at that moment in time. This increases overall system capacity towards what is optimal. Such benefits were not possible with only R99 fast power control.

We can infer that power control is done implicitly because when modulation and coding are changed based on CQI feedback received from the UE on UL HS-DPCCH, Node-B will also adjust its transmission power. Every CQI is associated with a reference power offset that is used by the UE when it calculates the CQI to send to the Node-B [TS 25.214, 6A]. This calculation is also dependent on the UE category.

Of course, open loop power control exists. The Node-B is commanded by the CRNC with specific power offsets. There is a power offset for HS-SCCH that’s relative to DL DPCCH power. For HS-PDSCH, where multiple codes are used, all codes will be transmitted with the same power [TS 25.214, 5.2.11]. The transmission that the Node-B can use for HS-PDSCH is indicated as a percentage of the total power available to the Node-B. This is indicated for every priority class with weights for every UE. Thus, differentiation in terms of priority and UE is partly implemented with these power weights [TS 25.433,]. It is then left to the Node-B to manage these power profiles efficiently. This is an implementation issue and has been the subject of many patents.

HSDPA has an associated channel in the UL (HS-DPCCH) that carries channel quality feedback and acknowledgments. CQI, ACK and NACK – all have their power offsets which are relative to UL DPCCH [TS 25.213,]. These offsets are signalled using NBAP to the Node-B.

Coming to HSUPA, the scenario is a little closer to the power control R99 UL channels. In DL DPCCH, there are always non-zero bits of TPC (Transmit Power Control) which are used for inner loop power control of the UL DPCCH and UL DPDCH. Power control of UL DPDCH is closely tied to UL DPCCH. There is defined offset between these two channels in terms of gain factors. These are either signalled at RRC or computed at Layer 1. Every TFC (Transport Format Combination) has a defined pair of gain factors. When computed, rate matching attribute, number of transport channel bits after radio frame segmentation and number of DPDCH are taken in account [TS 25.214,].

In HSUPA, the channels in question are E-DPCCH and E-DPDCH. Power control of HSUPA UL channels are tied to DPCCH. In fact, there is a requirement that E-DPCCH can be transmitted only if DPCCH is also transmitted in the same slot [TS 25.211,].

Complexity of HSUPA power control comes from the fact that inner loop and open loop controls are intimately tied to each other. For example, E-DPCCH power is signalled by RRC and it is relative to DPCCH power offset [TS 25.213,]. This offset does not change often because it is fixed by RRC at SRNC. However, inner loop controls the power of DPCCH which in turn affects the power of E-DPCCH.

RRC also signals the power offsets for each E-DPDCH. These offsets or gain factors are associated with E-TFC. This design gives flexibility to use higher power when data rate is higher. Actual gain factors for each E-TFC is calculated by the UE. Calculations take into account the HARQ power profile which is signalled at RRC [TS 25.213,]. This is similar to the weights given for priority classes for HSDPA. The computed gain factors are quantized to reference gain factors signalled at RRC.

The idea of using these reference gain factors is that every MAC-d flow is associated with a certain Q0S. The HARQ power profile allows this QoS to be met. If a MAC-e PDU carries only one MAC-d flow the power profile can be easily met. More commonly, data from different flows may need to be multiplexed in the same PDU to make the best of available bandwidth. For this reason, RRC signals a sets of compatible MAC-d flows that could be multiplexed in the same MAC-e PDU.

Of course, the UE ought to choose an E-TFC according to the amount of data it has to send. This is the case with R99 when UE chooses a TFC. The additional control for E-TFC is that amount of power the UE is allowed to use. This affects the UE MAC in its choice of E-TFC for the next transmission. These grants which are basically expressed in relation to power are sent on E-AGCH and/or E-RGCH channels. Thus, these two DL channels introduced for HSUPA play an important part in HSUPA power control by not just changing the power but also affecting the amount of data the UE is allowed to send. This can be seen as an enhancement or constraint to R99 inner loop power control.

An additional comment is that whatever happens, total transmission power from either the Node-B or the UE is fixed to a certain level. This level should never be exceeded. So if UL DPCCH is transmitted at a certain power, offsets and grants can be applied bearing in mind the upper limit. At the Node-B, there is an optional parameter that specifies the maximum power of HS-PDSCH, HS-SCCH, E-AGCH, E-RGCH and E-HICH taken together.

We now know that HSUPA inner loop power control is partly done using TPC bits of DL DPCCH. What happens if only HSDPA is required in the DL and DL DPDCH is redundant? This problem has been solved with the introduction of a new DL channel called Fractional DPCH (F-DPCH). This is a light-weight channel that functions just like DL DPCCH. The reason for introducing a new channel is to have minimum impact on previous releases of the standard. It was difficult to modify the slot formats of DL DPCH in a backward compatible manner since DL DPCCH and DL DPDCH are time multiplexed.


  1. Harri Holma and Antti Toskala, WCDMA for UMTS, Second Edition, John Wiley & Sons, 2002.

Read Full Post »

Power Control in UMTS

In this post I will look at different power control mechanisms that are present within UMTS. Those new to this topic will find it informative. For those familiar with the technology, it is hoped that this post will bring greater insight that are often not mentioned in the standards. Standards tell us what is to be done, not how (implementation issue) or why (design issue which happens during study, analysis and writing of standards).

It is a known fact that power control is important in any system, particularly in an age of global warming in which everyone is trying to achieve a lean carbon footprint. When it comes to mobile phones, the idea is to extend battery life by using the minimum possible power while maintaining reliable communications. From the point of any cellular network, proper power control helps in keeping interference at a manageable level while improving capacity and the overall service to the mobile subscriber.

UMTS, unlike GSM, has a greater need to combat the near-far problem. A UE close to the Node-B transmitting at the same power as another at the cell edge, will potentially block out the latter. To maintain reliable links to all UEs, the received power at the Node-B should be about the same. This means that propagation path loss between theUE and the Node-B should be taken into account. In an ideal environment, this alone is sufficient. But real environments are rarely ideal. Channel conditions vary, in the short term and in the long term. Recognizing all these, we can relate easily to the three main power control mechanism in UMTS:

  1. Open loop power control: this relates directly to the path loss. As the name suggests, this control has no feedback. It simply sets the initial power at which the UE should transmit. This initial settings happens via RRC signalling. This control is in the UE and the RNC.
  2. Outer loop power control: this relates to long term variations of the channel. A target SIR is specified. If the received SIR is less than this target, transmit power needs to be increased. Otherwise, it needs to be decreased. In practice, DL target quality is in terms of transport channel block error ratio (BLER). The BLER can be related to a target SIR. If the received SIR is less than the target, BLER is likely to be not met. Alternatively, if the BLER is more than the target, transmit power has to be increased. This control is in the UE and the RNC. This is also known as slow closed loop power control. It happens at the rate of 10-100 Hz.
  3. Inner loop power control: this is also known as fast closed loop power control. It happens at a rate of 1500 Hz to combat fast fading. This control is with the UE and the Node-B. While outer loop control is set at RRC level and executed at Layer 1, fast power control happens at Layer 1 in order to meet the BLER target set by outer loop control. The effect of this control is that even in a fading channel, the received power is maintained constant so as to achieve the BLER target. This is represented in Figure 1 [2].

Figure 1: UMTS Fast Power Control Combating Fast Fading

Fast Power Control UMTS

Fast power control is important in keeping interference to a minimum and improving capacity. Without it, transmit power would have higher to meet quality targets. The gain from this control is as much as 5.8 dB at the receiver for pedestrian speeds for 8kbps speech with 10ms interleaving and antenna diversity. The gain is less at the transmitter and for higher speeds [2].

The problem with fast power control are the spikes in power when deep fades are encountered. This may be necessary for the connection but it also introduces interference to neighbouring cells where the UEs may not necessarily be experiencing adverse channel conditions. Recognizing this fact, the rate of fast power control can be adjusted to suit the need. For example, for non-real time services, a higher BLER can be tolerated. As a result, it is permissible to be in a fade and lose packets, leaving it to RLC to retransmit. So although 1500 Hz is the maximum rate, both UL and DL allow for lower rates by which it is meant that TPC bits do not change from slot to slot. For DL power control, DPC_MODE controls this behaviour enabling the use of same TPC for 3 slots. For UL power control, ‘Power Control Algorithm’ tells the UE how TPC bits are processed. For the slower rate, the UE considers TPC bits from 5 slots before changing its power [TS 25.214].

Anyone familiar with the operations of transport channels and their multiplexing on a CCTrCH will realize the difficulty of meeting BLER target. The reason is each transport channel can have its own quality target based on the Q0S of the service it carries. How can we then meet diverse BLER targets of transport channels mapped to the same physical channel? I am not aware of any solutions to this problem but my belief is that in practice only one BLER target is used. In other words, the target is used as an indication of the RL quality and not the QoS of the Radio Access Bearer. Service QoS is implemented differently in terms of bandwidth, level of error protection (CRC), channel coding (convolutional vs turbo) and spreading gain (spreading factor).

It must be mentioned at this point that BLER target cannot sometimes be met. For example, if the Node-B is already transmitting at its highest possible power, there is no way it can respond positively to a TPC “UP” command. Decisions have to be made by Admission Control in the SRNC. Possibly, some calls have to be dropped. Possibly, data rates have to be reduced to meet the target BLER. It has been shown that dynamic bearer switching in bad channel conditions improves BLER performance [4]. For example, in bad channels when meeting BLER is proving to be difficult, the service is switched from 384 kbps (10 ms TTI, SF 8, 12 TBs) to 128 kbps (20 ms, SF 16, 4 TBs). This is far better than dropping the call.

Differentiation of power control happens at a finer level too. In the UL, DPCCH and DPDCH operates at different power levels and these can vary with the TFC. Every TFC has its own gain factors, βc and βd that adjust the transmit power. These gain factors are set independent of fast power control. For PRACH, the preamble and the message parts can operate at different power levels. If E-DCH is used, the power levels of E-DPCCH and E-DPDCH can be different and are in relation to DPCCH and DPDCH powers. In the DL, DPCCH and DPDCH are time multiplexed and each can operate at a different power. In addition, different fields of DL DPCCH can operate at different power levels. Different DL channels can operate at different power levels. If compressed mode is enabled, further dynamics are involved. The step sizes (in dB) for power adjustment can also be varied at the same rate as outer loop power control. Specific rules apply for F-DPCH. Power control in HSDPA is done very differently from R99 channels. HSDPA and E-DCH power control will be a separate post. Likewise, power control during SHO will be a separate post.

In conclusion, power control is extremely important in UMTS. The design contains a lot of flexibility to allow power control at different levels.

References/Further Reading:

  1. Fredrik Gunnarsson and Fredrik Gustafsson, Control theory aspects of power control in UMTS, Control Engineering Practice, Volume 11, Issue 10, Pages 1113-1125, October 2003.
  2. Jaana Laiho, Introduction to RRM/PC, (Powerpoint presentation), Nokia1999.
  3. Bo Bernhardsson, Power Control in WCDMA–Background, Dept. of Automatic Control, Lund Institute of Technology.
  4. Wolfgang Karner, Philipp Svoboda, Markus Rupp, A UMTS DL DCH Error Model Based on Measurements in Live Networks, Institut f¨ur Nachrichtentechnik und Hochfrequenztechnik, Technische Universit¨at Wien, Austria.

Read Full Post »

Older Posts »