|
4G/LTE - Logical Channel Prioritization |
||
|
Logical Channel Prioritization
What is the Logical Channel Prioritization and why we need it ? Before I answer this, let's think of high level view (100 km view). In the data transmission process, the data flow / storage from Logical channels to physical channel can be illustrated as below. As shown here, there are multiples of Logical Channel Data which has data to be transmitted through Physical data pipe. As you can see here, Physical Pipe is single and relatively limited resource and it can be transmitted only once in a TTI (NOTE : You may say the physical pipe can also be a multiples considering multiple codewords carrier aggregation, but logically with the view point of MAC scheduler it can be considered as a single / aggregated pipe). If there are not so much data waiting in each of the logical channel buffer, there wouldn't much things to worry about, but if there are large amount of data waiting in every logical channels and those data cannot be packed into the single transmission of physical pipe, the problem would happen. The scheduler should decide which of the data should be transmitted right away and which of the data should wait for next chance. It means the scheduler should set a certain priorities for each of the logica channel and this process/rule is called Logical Channel Prioritization.
NOTE : To be honest, I didn't have much understanding on this topic before I write this note. The first big picture that I got about this topic was from this excellent blog. I just tried to understand this blog and write/illustrate in my own words and imagenation. I strongly recommend the readers to read the through the blog.
Now let's look into the details procedure of the logical channel priotization algorithm.
Then what would be the solution to handle those competing situation ? As briefly mentioned above, the simplest idea is to set the priority for each of Logical channels (In real impelmentation, this priority for each logical channel is set by RRC message as shown in RRC Parameter).
Step 1 : Let's assume that there are four Logical channels with a lot of data to be transmitted and the priority is set as shown below. (NOTE : Low Priority value indicaters High Priority..meaning that priority 0 is the highest priority and priority 0 is the lowest priority in this example).
Step 2 : Pack the data into the physical pipe based on Priority. In this case, the whole data of each logical channel get packed into the physical pipe based on priority as shown below. In this example, the physical pipe got full when Logical Channel 0,1,2 are packed into the physical pipe and Logical channel 3 should wait for next chance.
Step 3 : (If there is no other data flowing into Logical Channel 0,1,2), Logical Channel 3 would get the chance to be packed into the physical pipe at next transmission as shown below.
Is just Prioritization Enough ?
Would just prioritization setting be enough for the issues that we have ? In most cases this would work. However, there can be some corner cases where setting the prioritzation cause another problem. Let's think of a specific case as illustrated below. At TTI 1, all the data with prioity 0,1,2 got packed into the PHY/MAC packet.. but at the same time new data flow into the logical channel buffer as shown below.
What would happen to LoCh 3 at the next TTI ? Would it get the chance to get packed into PHY/MAC packet ? Still No because there are higher priority data waiting in the buffer even at the next TTI. What would happen this kind of situation repeats ? That is, what would happen to low priority channel data if high priority data keep flowing into the logical channel buffer ? If we pack the data into PHY/MAC pipe only based on priority, the low priority channel would never get a chance to transmit the data. This kind of situation is called Starvation.
Set the limit for Each Priority
What would be the solution for the starvation problem mentioned above ? One simple solution is to set some limit for each logical channel to push the data into the PHY/MAC pipe at once. In this way, even the lower priority channel would get higher chance to push its data into the PHY/MAC pipe even when high priority buffer is not completely empty as illustrated below.
NOTE : PBR in this diagram stands for prioritisedBitRate which is configured by RRC.
Setting the priority and PBR is good enough ?
Definately it would be good enough for most of the case, but there always can be some corner case to cause difficulties (issues). Let's assume that data keep flowing into the high priority logical channels. In this case, even we set PBR, it is likely that low priority channel suffer from starvation. To resolve this kind of issues, we put another restriction for the prioritization. It is a kind of timing (time duration) restriction for a logical channel to maintain the given priority. There is a kind of count-down timer for each logical channel and everytime a logical channel transmit a data with the size of PBR, the timer get descreased by 1. Once the count down timer become negative, it should give up its turn to transmit the data even if it has high priority. This timer prevent a channel to permanently monopolize the PHY/MAC pipe even if it has high priority and has some data to send all the time. This count-down timer is configured by the RRC parameter : bucketSizeDuration.
Who should care about the logical channel prioritization ?
Who is controlling the logical channel priotization ? In terms of 3GPP specification shown below, Logical Channel Priotisation is for UE Uplink and is part of MAC layer functionality.
< 36.321-Table 4.4-1: MAC function location and link direction association. >
As explained above, there were a few parameters for the operation of logical channel priotization : Priority, PBR(PriotisedBitRate), BSD(bucketSizeDuration). All of these are configured by RRC message as shown below.
LogicalChannelConfig ::= SEQUENCE { ul-SpecificParameters SEQUENCE { priority INTEGER (1..16), prioritisedBitRate ENUMERATED { kBps0, kBps8, kBps16, kBps32, kBps64, kBps128, kBps256, infinity, kBps512-v1020, kBps1024-v1020, kBps2048-v1020, spare5, spare4, spare3, spare2,spare1}, bucketSizeDuration ENUMERATED { ms50, ms100, ms150, ms300, ms500, ms1000, spare2, spare1}, logicalChannelGroup INTEGER (0..3) OPTIONAL -- Need OR } OPTIONAL, -- Cond UL ...,
Reference
|
||
