Posts Tagged ‘multiplex’

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 »