Feeds:
Posts
Comments

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.

PHSI

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.

PHSF

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.

PHSM

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.

PHSS

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.

PHSV

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
HSDPA MAC Mux

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
HSUPA MAC Mux

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, 9.2.1.31lc]. 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, 4.2.1.2]. 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, 5.1.2.5.3].

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, 5.2.1.3].

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, 4.2.1.3]. 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, 4.2.1.3]. 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.

References:

  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 »

GPRS Dual Transfer Mode

They say necessity is the mother of invention. So when GPRS saw the upcoming competition from UMTS it had to invent new methods to keep itself alive longer in the cellular world. The greater truth is that everyone knew that UMTS will not replace GSM/GPRS overnight. Rather, these two access standards will co-exist for a long time to come before 3G completely replaces 2.5G. More than competition, it was completion and cooperation.

It was correctly envisaged that this coexistence will happen for the following reasons:

  1. Going by demand, deployment of 3G cells will happen in phases whereby urban areas could be covered by 3G while rural areas continue on 2.5G. This means that movement from urban to rural will trigger an inter-RAT handover.
  2. 3G may be deployed at the level of microcells while at the macrocell level 2.5G may be used.
  3. Operators have invested considerably in 2.5G and the move to 3G will at best be a transition.
  4. Because WCDMA at 2100 MHz generally lacks the indoor coverage that’s possible with GSM 900 MHz, this leads to another use case for inter-RAT handover.
  5. It will take time for users to switch consumption patterns, to move from voice-centric to data-centric.
  6. It will take time for users to give up their old handsets in favour of 3G-enabled handsets.

Whatever be the case, one of the keys problems for GPRS is that CS and PS traffic cannot happen simultaneously. How then can we meet user expectations when an inter-RAT handover from UMTS to GPRS will necessarily mean dropping the packet connection?

GPRS standards provides for three classes of MS:

  • Class A: supports simultaneous attach, simultaneous activation, simultaneous monitor, simultaneous invocation and simultaneous traffic. A CS call in the middle of PS call will not disrupt the latter. This class of a mobile may even require two transceivers because CS and PS could be on different frequencies. RF duplexers may be needed along with multiple call processing units. There is no coordination between the two service domains. As such, such a mobile is quite complex and rarely implemented. The cost of such a mobile is also likely to be high and with possibly low battery life.
  • Class B: supports simultaneous attach, simultaneous activation and simultaneous monitor. Service invocation and traffic are mutually exclusive. This means that a CS call in the midst of a PS call will suspend the latter.
  • Class C: the two domains are mutually exclusive even for attach. If MS is used for the CS domain (possibly chosen by the user), PS domain becomes unavailable.

Thus, although the class A mobile will suit inter-RAT handover from UTRAN, it is prohibitively complex. To overcome this problem, designers have standardized the Class A Dual Transfer Mode (DTM) MS which can be seen as a subset of a Class A MS. This work started in November 1999. Today it is fairly stable and we are beginning to see DTM mobiles in the market [1]. Its characteristics are the following:

  1. Simultaneous traffic on both domains is possible and network coordinates this. Thus, the domains are not independent as a true Class A MS. Changes in the network are necessary to enable this coordination. In particular, the BSS maintains a mapping of the IMSI and TLLI. This enables the BSS to “page” a mobile (using PACCH) in Packet Transfer Mode for an incoming CS call. Thus, even without a Gs interface, such paging coordination is possible. This is a new network mode known as NMO-II bis.
  2. While it is true that a CS call can be added to an MS in Packet Transfer Mode, this happens in three stages. TBF is released. A dedicated connection is initiated. Finally, the MS transits to DTM for re-establishing the data connection. The state transitions are depicted in Figure 1.
  3. Resources assignments towards DTM state are made using one of three messages: DTM Assignment Command (generally used when CS resources have to be reallocated), Packet Assignment Command (when only PS resources have to be added while keeping CS resources the same), Main DCCH Assignment (for single timeslot packet signalling on main DCCH).
  4. CS and PS are carried on the same frequency. The use of timeslots is also restricted. Both calls could be shared on a single slot. In this case, both are half-rate channels (TCH/H + PDTCH/H). To clarify, although an RLC/MAC block is sent in four bursts, at half rate it is physically sent over 8 TDMA frames. If multislots are used, the slots have to be contiguous (TCH + multiple PDTCH). Although multislot approach gives higher data rates, in the event of a handover, it will be difficult to find just as many empty slots in the target cell.
  5. To simplify signalling procedures, main DCCH can be used for packet procedures. Thus, an MS is dedicated mode can be paged for a packet call using the main DCCH. Likewise, the MS can request to perform Cell Update or Routing Area Update during a CS call using the main DCCH.
  6. Use of main DCCH for PS signalling is on SAPI 0. For the purpose of demultiplexing, a new protocol discriminator (PD) has been defined – GPRS Transparent Transport Protocol (GTTP). All messages with this PD are passed transparently by the BSS to the SGSN. This reduced the congestion caused by GPRS signalling that happens on the border of RA/LA.
  7. The use of main DCCH for PS domain signalling may affect the signalling of an active CS call. As an alternative, new allocations using DTM procedures can be used. These may reallocate resources of the ongoing CS call.
  8. Certain things can be coordinated between the two domains – measurements, timing advance, power control.
  9. An MS in DTM, can be commanded by the BSS to make a handover. MS will not perform any cell reselection and NC mode does not matter.
  10. An MS supporting a certain multislot class will support all lower classes as well.
  11. While a non-DTM MS will support dynamic allocation and fixed allocation, a DTM mobile can have exclusive allocation in the uplink as an extra.
  12. It will be clear from Figure 1, that a dedicated connection cannot be released while maintaining the TBF. Thus, PS call will be temporarily suspended before it is again established. However, there is an enhanced CS release procedure by which the MS may be sent SI/PSI to ease re-entry into Packet Transfer Mode. PSI 14 has been defined for this purpose which may received in DTM state. Packet CS Release Indication (on PACCH), Packet SI Status, Packet PSI Status and Packet Serving Cell Data (PSCD) are also used in this regard.

Figure 1: RR Operating Modes and State Transitions

DTM States

From my search on the Internet, I discovered that one common class implemented by mobile phone vendors is the DTM Multislot Class 11. The technical specification of Nokia N95 states a speed of DL/UL 177.6/118.4 kbps. Given that Multislot Class 11 represents 4 Rx, 3 Tx and 5 active slots per frame, it is not clear how these data rates have been obtained.

Overall, DTM is a significant feature for a GPRS phone. Its has great value within a dual-mode phone. Users may notice slower data rates following a handover from UTRAN, but at least they will not lose their data connection; nor will they get into a habit of terminating their voice calls to get their important data through. Eventually, DTM will not be required as we move to an all-IP core and the inevitable death of CS domain. In the meantime while we have it, we need to ask one question: How often do we download/upload data while on a voice call?

References:

  1. List of S60 devices supporting GPRS Class A (Dual Transfer Mode), Nokia Forum, 27 Sept 2007.
  2. Mark Pecen and Andrew Howell, Simultaneous Voice and Data Operation for GPRS/EDGE: Class A Dual Transfer Mode, IEEE Personal Communications, April 2001.

Read Full Post »

Identities of a Dual-Mode Phone

This post is not meant to be comprehensive but I shall attempt to cover the most important identities used to identify the UE/MS. It has been a difficult task the reason being that information is spread across many specifications. If there are errors, do let me know. I also appreciate assistance on making this list complete.

Identities are summarized in Table 1. Shaded cells refer to group identities. Many of these identities can exist at the same time. Some identities are mutually exclusive. For example, TLLI cannot exist at the same time as C-RNTI. The former’s context is with the GPRS CN and the latter’s is within UTRAN.

An RNTI (Radio Network Temporary Identifier) exists only when the UE has an RRC connection. Depending upon the context and allocator, different RNTIs exist as listed in Table 1. RNTIs are deallocated when RRC connection is released.

Table 1: UE/MS Identities

Identity

Description

Length

(bits/

digits)

Context

C-RNTI

Cell Radio Network Temporary Identifier

  • Allocated by the CRNC.
  • Unique within the cell controlled by the CRNC.
  • Can be reallocated when UE changes cell with a Cell Update procedure.
  • Deallocated when RRC connection is released
  • Used by MAC to address a UE-UTRAN connection when DCCH/DTCH are mapped to common transport channels.
  • Can be used by MAC on UL and DL transport channels.

16

UE, UTRAN

DSCH-RNTI

Downlink Shared Channel Radio Network Temporary Identifier

  • Used only for TDD.
  • Used on the SHCCH.

16

UE, UTRAN

E-RNTI

E-DCH Radio Network Temporary Identifier

  • For E-DCH (HSUPA) only.
  • Two variants are possible: primary and secondary: both can be active at the same time.
  • RRC signalling configures the UE to use either primary or secondary.
  • Identity is used by PHY to address the UE on E-AGCH. Identity is used as a mask on the 16-bit CRC.

16

UE, UTRAN

G-RNTI

GERAN Radio Network Temporary Identifier

  • Applicable from Release 5 onwards for GERAN Iu Mode.
  • Allocated by RRC in the Serving BSC and unique within the BSC.
  • Reallocated when the SBSC changes
  • Used at RLC/MAC during contention resolution. If there is no allocation, a random G-RNTI is used; otherwise the allocated identity is used.
  • Deallocated when RRC connection is released.
  • Derived from TLLI codespace. Used on Iu interface and quite similar in purpose to TLLI used on A/Gb.

UE, GERAN, CN

H-RNTI

HS-DSCH Ratio Network Temporary Identifier

  • For HSDPA only.
  • Identity is used by PHY to address the UE on HS-SCCH. Identity is used as a mask on the 16-bit CRC.

16

UE, UTRAN

IMEI

International Mobile Station Equipment Identity

  • Unique number allocated to each Mobile Equipment (ME) in the PLMN.
  • Unconditionally implemented by the MS manufacturer.
  • Generally used to block stolen mobiles. IMEI can be changed but it is illegal in some countries (UK for example).
  • Composed of Type Allocation Code (TAC) + Serial Number (SNR) + spare digit = 8 + 6 + 1= 15 digits.
  • IMEI will be used for emergency call establishment and re-establishment only when SIM/USIM and IMSI are not available.

15

UE, CN

IMEISV

International Mobile Station Equipment Identity with Software Version Number

  • Similar to IMEI; composed of Type Allocation Code (TAC) + Serial Number (SNR) + Software Version Number (SVN) = 8 + 6 + 2= 16 digits.
  • Optionally included by the mobile in Authentication and Ciphering Response.

16

UE, CN

IMGI

International mobile group identity

??

??

??

IMPI

IP Multimedia Private Identity

  • Used in IMS.
  • Could be based on IMSI if not allocated explicitly.
  • Of the form “user@domain”.

Textual

UE, IMS

IMPU

IP Multimedia Public identity

  • Used in IMS.
  • Of the form “sip:user@domain”.

Textual

UE, IMS

IMSI

International Mobile Subscriber Identity

  • Variants exist based on the type of CN: IMSI-DS-41, IMSI-GSM-MAP, IMSI-and-ESN-DS-41. Here we are refer to IMSI-GSM-MAP when we say IMSI.
  • Allocated to each mobile subscriber in the GSM/UMTS system.
  • ITU-T refers to this as International Mobile Station Identity.
  • This is the common identity across both CN domains.
  • RAN uses it for coordination with UE. CN transfers identity to RAN using RANAP. RAN deletes it when RRC connection is released.
  • Consists of MCC (3 digits) + MNC (2 or 3 digits) + MSIN.
  • Used by RRC for CN originated paging.
  • Generally avoided on the air interface in lieu of TMSI or P-TMSI unless the latter is not recognized by the CN or not available at the mobile.
<= 15

UE, CN

IMUN

International Mobile User Number

  • A diallable number allocated to a 3GPP System user.
  • Not sure how this is used.

??

??

IUI

International USIM Identifier

??

??

??

LMSI

Local Mobile Station Identity

  • Allocated by the VLR and mapped to IMSI.
  • Used for communication with HLR although HLR makes no use of it. HLR merely sends it back in its responses.
  • Facilitates easy search of database at the VLR.
  • Advantage is that TMSI could be reallocated while LMSI is persistent.

32

VLR

MSID

Mobile Station Identifier

??

??

??

MSIN

Mobile Station Identification Number

  • Part of IMSI.
  • Identifies the mobile within the PLMN.
  • The leading digits may in some cases used by the PLMN to identify quickly the HLR.
  • If MNC has just 2 digits, this identity has a leading zero.

<= 10

UE, CN

MSISDN

Mobile Station/Subscriber ISDN Number

  • Number by which the mobile can be called.
  • Composed of Country Code (CC) + National Destination Code (NDC) + Subscriber Number (SN).
  • An NDC is required for each PLMN. Some PLMNs may require more than one NDC.
  • Parts of the identity are used by SCCP for routing messages to the HLR.

Variable??

UE, CN, PSTN/ISDN

MSRN

Mobile Station Roaming Number

  • Allocated by the VLR.
  • Used to route calls to the mobile.
  • Passed by the HLR to GMSC for routing purpose.
  • Identity addresses the MSC/VLR where the mobile currently has a context.
  • Has a structure similar to MSISDN.
  • A mobile may have more than one MSRN.

Variable??

UE, CN

MUI

Mobile User Identifier

??

??

??

NMSI

National Mobile Station Identifier

  • Part of IMSI.
  • Composed of MNC + MSIN.
  • Managed within relevant national bodies.

<= 12

UE, CN

NUI

National User / USIM Identifier

Network User Identification

??

??

??

P-TMSI

Packet Temporary Mobile Subscriber Identity

  • Variants exist based on the type of CN: P-TMSI-GSM-MAP, P-TMSI-and-RAI-GSM-MAP. Here we refer to P-TMSI-GSM-MAP when we say P-TMSI.
  • Used instead of IMSI to implement subscriber confidentiality in the PS domain.
  • Allocated by SGSN which maps it to the IMSI.
  • Extensively used by GMM.
  • Generally reallocated when Routing Area changes. Has local context within a RA, outside which it has to be combined with RAI.
  • Used by RRC for CN originated paging. If it exists, preferred over IMSI for packet paging.
  • A P-TMSI signature exists to enable GMM establish the context of a mobile.

32

UE, CN

S-RNTI

SRNC Radio Network Temporary Identifier

  • Allocated by the SRNC and unique within the SRNC.
  • Reallocated during SRNC Relocation.
  • Deallocated when RRC connection is released.
  • A shorted version (10 bits) exists for signalling purpose only during a handover to UTRAN.

20

UE, UTRAN

TLLI

Temporary Logical Link Identity

  • Used on the GPRS air interface (RLC/MAC) to address the mobile.
  • Allocated by the MS based on P-TMSI (local or foreign TLLI) or directly (random TLLI).
  • Auxiliary TLLI is allocated by the SGSN but this is no longer required from R99 onwards.
  • Part of the TLLI codespace is reserved for G-RNTI.
  • Used by LLC in SGSN to uniquely identify the MS.
  • TLLI along with NSAPI is used by SGSN to identify the PDP context to which a packet belongs.

32

UE, GERAN, CN

TMGI

Temporary Mobile Group Identity

  • Used to identify an MBMS Bearer Service.
  • Allocated by BM-SC.
  • Used for either broadcast or multicast service.
  • This is the radio resource equivalent of MBMS Bearer Service Identification consisting of IP multicast address and APN.
  • Contains 24 bits of MBMS Service Id and optionally MCC (12 bits) MNC (12 bits) if the session is from a non-local PLMN.
  • Identity is used by RR/GRR for packet paging procedures for MBMS (pre-)notification. An optional MBMS Session Identity is used along with TMGI if notification is done on A/Gb mode.
  • Identity used by Layer 3.

24, 48

UE, CN

TMSI

Temporary Mobile Subscriber Identity

  • Variants exist based on the type of CN: TMSI-DS-41, TMSI-GSM-MAP, TMSI-and-LAI-GSM-MAP. Here we are refer to TMSI-GSM-MAP when we say TMSI.
  • Used instead of IMSI to implement subscriber confidentiality in the CS domain.
  • Allocated by VLR which maps it to the IMSI.
  • Extensively used by MM.
  • Generally reallocated when Location Area changes. Has local context within an LA, outside which it has to be combined with LAI.
  • Used by RRC for CN originated paging.
  • Format of TMSI is not standardized.

32

UE, CN

U-RNTI

UTRAN Radio Network Temporary Identifier

  • Identifies the UE uniquely within UTRAN.
  • Made of two parts: SRNC identifier (12 bits) + S-RNTI (20 bits).
  • Used to identify UE in many RRC procedures in CELL_FACH (Cell Update, URA Update, UTRAN Originated Paging).
  • Used by MAC to address a UE-UTRAN connection when DCCH/DTCH are mapped to common transport channels.
  • Not used by MAC in the UL but can be used by RRC. Used by MAC only in the DL when DCCH is mapped to FACH for SRB1 (alternative is the C-RNTI).
  • During a handover to UTRAN, RRC signalling uses U-RNTI-Short in which the S-RNTI component has only 10 bits. The shortened S-RNTI is expanded to 20 bits to (MSBs set to zeros) and the final U-RNTI is generated.
  • Rel5 RRC signalling uses this in a modified form to address a group of UEs for RRC connection release.

32

UE, UTRAN

Some identities need explanation. Since C-RNTI and U-RNTI are usually meant for use in CELL_FACH states, it may be puzzling to note that these can be reallocated in CELL_DCH state. Such a reallocation will generally happen in the case of handovers when the CRNC or SRNC change. The UE will merely store the identities until a later time when they may be required. For example, after the handover the channel conditions may worsen triggering a Cell Update procedure on CCCH. This procedure will then make use of the U-RNTI within RRC Cell Update message. The Cell Update Confirm may be on CCCH or on DCCH. In the former case, the U-RNTI will be returned within the message. In the latter case, U-RNTI is used at MAC. Either way, Cell Update Confirm may in its turn allocate new identities.

Specifications [TS 24.008] define the conditions under which the mobile shall use IMEI, IMSI, TMSI or P-TMSI. Some of these have been mentioned in Table 1. Specification titled “Numbering, addressing and identification” [TS 23.003] is a good source of information. The use of some of these identities by RR/GRR/RRC can be found in relevant specifications [TS 44.018, TS 44.060, TS 44.160, TS 25.331]. The use of E-RNTI and H-RNTI is mentioned in a PHY layer specification [TS 25.212]. Some details on TMGI is in an MBMS specification [TS 23.246].

Other important identities for the mobile are DLCI, XID, NSAPI and TI. Because these pertain more to connections at a specific layer rather than the MS/UE as a whole, they have been left out of this discussion.

 

 

Read Full Post »

Following the article on GPRS cell reselection and NACC, I thought it was appropriate to mention neighbouring cells that the MS monitors. The list of neighbour cells is formed by a complex process in which information is gathered from different sources. As an easy reference, this post attempts to summarize this process. This post will look at:

  • GSM Neighbour Cell List for GSM
  • GSM Neighbour Cell List for GPRS

The term “GSM Neighbour Cell List” is so named to distinguish it from 3G Neighbour Cell List. It is applicable to GPRS as well. It is simply a list of neighbours that the MS maintains. It makes measurements on these cells and reports them to the network if configured to do so. Cell reselection depends on these measurements.

The final list that the MS maintains is the Neighbour Cell List which is a concatenation of GSM Neighbour Cell List and 3G Neighbour Cell List. For the purpose of reporting measurements, the lists are treated separately.

Every cell maintains a BCCH Allocation List or BA List which is a list of frequencies of neighbouring cells. This information is useful for the MS for performing and reporting measurements, and eventually in cell reselection and handover. The BA List is formed from information in the SI. For GPRS, BA(GPRS) exists which is formed from information in PSI. If the cell does not have a PBCCH, BA(GPRS) equates to BA(list) obtained from SI. The key difference between BA(list) and BA(GPRS) is that the former is only a frequency list and the latter is a list of frequencies paired with Base Station Identification Code (BSIC). BSIC allows for cell changes across cells that are not necessarily neighbours in a geographic sense. So an MS could do a cell reselection across cells with the same frequency but different BSIC. Such a possibility arises if the immediate neighbours are hidden (no line of sight) whereas a far away cell can provide better service due to clear LOS radio path.

Figure 1: GSM NC List (GSM)
GSM NC List - GSM

Now let us look at the formation of GSM Neighbour Cell List for GSM (Figure 1). In idle mode, BA(list) is formed from SI2/2bis/2ter while in dedicated mode SI5/5bis/5ter are used. If the latter set is missing completely in dedicated mode, the former will be used. SI2quater enhances the BA(list) by providing BSICs. The combination of the two makes the GSM NC List. SI2quater was introduced for enhanced measurements, a feature I will describe in a separate post. In dedicated mode, Measurement Information (MI) is used instead of SI2quater but the end result is the same as in idle mode. If SI5 and MI are both not sent to the MS in dedicated mode, the GSM NC List in dedicated mode is same as in idle mode.

Figure 2: GSM NC List (GPRS)
GSM NC List - GPRS

Figure 2 illustrates the formation of GSM NC List for GPRS. In packet idle mode without PBCCH on the cell, the BA(GPRS) is only a frequency list. Combined with BSIC information in SI2quater this becomes the GSM NC List. If PBCCH is present, PSI3/3bis is used to make the BA(GPRS) which contains pairs of frequency and BSIC. This is also the GSM NC List. In packet transfer mode, the GSM NC List formed in packet idle mode is reused. Elements of this list can be deleted or new elements can be added using Packet Measurement Order (PMO) or Packet Cell Change Order (PCCO). Addition happens on the GSM NC List and is based on pairing of frequency and BSIC. Deletion happens on the BA(GPRS) and is based on frequency which implies that all cells with that frequency are removed from the GSM NC List regardless of the BSIC. Such a definition is useful if the BA(GPRS) is only a frequency list as in a cell without PBCCH.

Among the cells in the GSM NC List for GPRS, some may be cells with both Iu and A/Gb modes. There may be cells with only Iu mode. In the final count, the list can have a maximum of 96 cells and 32 unique frequencies.

Read Full Post »

Older Posts »