I would be almost impossible to explain everything about LTE MAC in a single column without making it a thick book or without making everybody falling in sleep since MAC is the center of all LTE procedure. You would remember that I wrote a long column for RACH procedure, but that complicated procedure is just a small portion of LTE MAC procedure.

In this column, I would focus only on MAC overview and MAC PDU structure for SCH (data transmission and reception) and the other part of the MAC will be dealt in separate columns.

MAC Structure Overview

Let's start with overall MAC procedure. It is always good to use an illustration/diagram to give a big picture of anything.. but ironically it would be easily overlooked if we present something in diagram. So my recommendation is to try to convert the illustration into a verbal description and to convert a verbal description into a form of illustration. At least this kind of conversion process has helped me a lot.

Let's start this conversion with the following diagram from 36.321. You may have seen this from too many different LTE training material.. and overlooked it almost every time -:).

36.321 Figure 4.2.1-1. PCCH and the BCH part of BCCH bypass HARQ, and Random Access Control has no logical channel above it.

Let's just try to "read" (not "see") this illustration. I read as follows.

• i) All the logical channes (PCCH, BCCH, CCCH, DCCH, DTCH) goes through MAC layer. (too simple reading ? -:)
• ii) It seems that PCCH does not get manipulated by MAC in any special way. It just looks as if it is by passing MAC process. It does not use HARQ procedure meaning 'no retransmission' mechanism being used.
• iii) CCCH, DCCH, DTCH all go through the same procedure (Prioritization, Mux/DeMux, HARQ).
• iv) Some BCCH goes through HARQ, but some BCCH does not go through HARQ. Do you know which BCCH go through HARQ and which does not ? BCCH for MIB does not go through HARQ, but BCCH for SIB go through HARQ. (But this HARQ is a little different from normal HARQ that we know of.. It does not expecting any ACK/NACK response from the reciever.. but perform 'retransmission' based on a predefined rule).
• v) Random Access process orignated within MAC layer, it does not have the correspoding logical channel. (This may apply to Msg1, Msg2 of RACH procedure.. Msg3,4,5 involves RRC layer intervention as well).

Let's read another important illustration from 36.321. Following shows the channel mapping for various downlink data. As LTE evolves, you would see more and more new channels are added and this mapping gets more complicated. At the first stage of LTE(Rel 8), we started with "Orange colored" channels and now (Rel 13) we see a several new colors (channels) as below. (If you like, refer to the same Figure in 36.321 Release 8 document and compare it with this)

< Based on 36.321 13.3.0 - Figure 4.5.3.2-1 >

The downlink mapping, drawn after 36.321 v13.3.0 Figure 4.5.3.2-1. Almost every logical channel ends on DL-SCH.

• The orange ovals are the Rel-8 channels, and the blue and grey ovals are later additions such as MTCH, MCCH, BR-BCCH and the SC-PTM channels.
• BCCH has two lines, one to BCH for the MIB and one to DL-SCH for the SIBs.
• The rightmost oval is labelled SC-MCCH a second time. Table 4.5.3.2-1 below shows that this oval is SC-MTCH.

Following is the table showing the exactly same mapping. The interpretation is exactly same as the figure shown above, it is shown just in a different format.

< Based on 36.321 13.3.0 - Table 4.5.3.2-1: Downlink channel mapping >

36.321 Table 4.5.3.2-1. BCCH is the only logical channel with two transport channels, BCH and DL-SCH.

I read as follows :

• i) PCCH (Logical Channel) is mapped only to PCH (Transport channel).
• ii) DL-CCCH, DCCH, DTCH are all mapped to DL-SCH.
• iii) Some BCCH is mapped to BCH and Some BCCH is mapped to DL-SCH. Do you know which one is which ? BCCH for MIB is mapped to BCH and BCCH for SIB is mapped to DL-SCH.

Let's do similar reading for Uplink channels as well. Unlike Downlink mapping, this uplink mapping hasn't changed since the initial LTE implementation.

< Based on 36.321 13.3.0 - Figure 4.5.3.1-1 >

The uplink mapping, drawn after 36.321 v13.3.0 Figure 4.5.3.1-1. CCCH, DCCH and DTCH share one transport channel.

• The note on the left says RACH has no higher layer, because it starts and ends in the MAC layer.
• The transport channel on the right is labelled DL-SCH in the drawing. In the uplink it is UL-SCH, as Table 4.5.3.1-1 below shows.

Following is the table showing the exactly same mapping. The interpretation is exactly same as the figure shown above, it is shown just in a different format.

< Based on 36.321 13.3.0 - Table 4.5.3.1-1: Uplink channel mapping >

36.321 Table 4.5.3.1-1. The RACH column is empty, because no logical channel maps to RACH.

• i) No BCCH, PCCH on Uplink path. (BCCH, PCCH is downlink only channels).
• ii) UL CCCH, DCCH, DTCH are all mapped to UL-SCH.
• iii) There is a special channel called 'RACH', but this does not have any corresponding logical channel.

Try this kind of 'reading' whenever you see any diagram.. very simple but it would really help.

Then try to correlate each messages in the call flow with the channel mapping. And the try to correlate this mapping with the diagrams described above. Ask a couple of questions to yourself, e.g which of these message use HARQ ? Which message is carried by a 'Common' channel and which messages are carried by a 'Dedicated' channel.

< Logica to Transpot Channel Mapping in Protocol Sequence >

The channel mapping along an initial attach. From RRC Connection Setup Complete onward, every message uses DCCH on DL-SCH or UL-SCH.

Overview of MAC Procedure

Almost every LTE procedure has a MAC part. The table below lists them with one line each, and most rows link to the page that covers the procedure in full.

MAC PDU Structure

A MAC PDU is a string of bytes, and the header is the only thing that tells the receiver where each part begins. So before the examples, you need the subheader formats that the receiver uses to cut the PDU apart.

MAC PDU Structure /MAC Header for RACH Response

MAC Header and PDU structure for RACH Response (also called as RAR or Msg 2) has special format which has completely different from the MAC Header/PDU for user data.  Overall structure for RAR MAC PDU structure is as shown below.  If you are not familiar with detailed RACH procedure, it would be difficult to make any practical meaning out of this diagram. So, I would recommend you to read at least following two sections first.

• An Example of Full RACH Process
• RACH Procedure during Initial Registration - RACH Procedure Summary

< 36.321 v13.03 - Figure 6.1.5-4: Example of MAC PDU consisting of a MAC header and MAC RARs >

36.321 Figure 6.1.5-4. An optional Backoff Indicator subheader comes first, then one E/T/RAPID subheader per MAC RAR, and padding is optional.

< 36.321 v13.03 - Figure 6.1.5-1: E/T/RAPID MAC subheader >

36.321 Figure 6.1.5-1. One octet with E, T set to 1, and the 6-bit RAPID.

< 36.321 v13.03 - Figure 6.1.5-2: E/T/R/R/BI MAC subheader >

36.321 Figure 6.1.5-2. One octet with E, T set to 0, two R bits and the 4-bit BI.

< 36.321 v13.03 - Figure 6.1.5-3: MAC RAR >

36.321 Figure 6.1.5-3. Six octets: R, an 11-bit Timing Advance Command, a 20-bit UL Grant and a 16-bit Temporary C-RNTI.

< 36.321 v13.03 - Figure 6.1.5-3a: MAC RAR for PRACH enhanced coverage level 2 or 3 >

36.321 Figure 6.1.5-3a. Five octets, because the UL Grant is only 12 bits for PRACH enhanced coverage level 2 or 3.

36.321 v19.3.0 keeps these RAR formats and adds two more, Figure 6.1.5-3b and Figure 6.1.5-3c, the MAC RAR for NB-IoT UEs and for NB-IoT UEs using PRACH preamble format 2. The Backoff Indicator subheader, when present, is always the first subheader of the RAR PDU.

• RAR has its own MAC PDU format : E/T/RAPID subheaders instead of R/F2/E/LCID.
• T tells the two subheaders apart : T = 1 carries a RAPID, and T = 0 carries a Backoff Indicator.
• The normal MAC RAR is six octets : 11-bit TA, 20-bit UL Grant and 16-bit Temporary C-RNTI.

MAC PDU Structure /MAC Header for DL-SCH, UL-SCH and MCH

Outside the Random Access Response, every MAC PDU on DL-SCH, UL-SCH and MCH uses one common format. The MAC header is a chain of subheaders, and the control elements, SDUs and padding follow in the same order as their subheaders.

In most case, one MAC PDU (MAC output) is made up of multiple chunks(MAC SDU = MAC Inputs) concatenated as follows;

< 36.321 v13.03 - Figure 6.1.2-3: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding >

36.321 Figure 6.1.2-3. The subheaders follow the order of the payload: MAC control elements, then MAC SDUs, then padding.

MAC Header Structure

NOTE : As you see below, the illustrated structure is from 3GPP v13.03 (Rel 13). In case of Rel 8, 9, the F2 is assigned as 'R (Reserved)' field. Most of the MAC decoding example in this page is based on Rel 8,9, so you would not see F2 field in those example. In the example that apply Rel 11 and higher, I will explicitely comment about it.

< 36.321 v13.03 - Figure 6.1.2-1: R/R/E/LCID/F/L MAC subheader>

36.321 Figure 6.1.2-1. Format A has F = 0 and a 7-bit L field, and format B has F = 1 and a 15-bit L field.

< 36.321 v13.03 - Figure 6.1.2-1a: R/F2/E/LCID/L MAC subheader >

36.321 Figure 6.1.2-1a. Format C has a 16-bit L field, which F2 = 1 signals.

< 36.321 v13.03 -Figure 6.1.2-2: R/F2/E/LCID MAC subheader >

36.321 Figure 6.1.2-2. Format D has no L field. It is used for the last subheader and for fixed-size MAC control elements.

36.321 v19.3.0 extends all three formats with an optional R/R/eLCID octet after the first octet. It is present only when LCID is 10000, the extended logical channel ID, and its 6-bit eLCID gives the logical channels 32 to 38.

NOTE : This subheader applies to the last subheader or Fixed sized MAC CE based on the following statement in 36.321-6.1.2 as stated below.

The last subheader in the MAC PDU and subheaders for fixed sized MAC control elements consist solely of the four header fields R/F2/E/LCID. A MAC PDU subheader corresponding to padding consists of the four header fields R/F2/E/LCID.

MAC LCID Field Structure

The LCID field is five bits, so it names at most 32 values. The low values name logical channels, and the high values name MAC control elements and padding. The same code point can mean different things in the downlink and the uplink, so always check which of the two tables applies.

< 36.321 v13.03 -Table 6.2.1-1 Values of LCID for DL-SCH >

36.321 v13.3.0 Table 6.2.1-1. From 11000 upward, the DL-SCH values name MAC control elements, SC-MCCH/SC-MTCH and padding.

< 36.321 v13.03 - Table 6.2.1-2 Values of LCID for UL-SCH>

36.321 v13.3.0 Table 6.2.1-2. From 10110 upward, the UL-SCH values name BSR, PHR and C-RNTI MAC control elements and padding.

Both tables above are from v13.3.0, and later releases have filled most of the reserved range. In 36.321 v19.3.0, DL-SCH values 01101 to 10111 all carry a meaning. For example, 10000 announces an extended LCID, 10010 is Activation/Deactivation of PDCP Duplication, and 10110 is Recommended bit rate. In the uplink, 01011 and 01100 both mean CCCH, and 01101 to 10101 carry values such as Timing Advance Report and SPS confirmation. A decoder written for Rel-13 reports these LCIDs as Reserved.

When you have BSR (Long BSR, Short BSR), you will have some additional information structured as shown in BSR page :

Let's understand the small keywords shown on the diagram. 36.321 6.2.1 MAC header for DL-SCH and UL-SCH has pretty good description.

• i) R : R means 'Reserved", meaning that it does not have any special meaning for now. It is always set to be '0' for now.
• ii) E : E means "Extension". This is an indicator to tell you if there is another fields following the subheader or not. '1' indicate there is at least one or more R/R/E/LCID fields following this field. '0' indicate there is no more R/R/E/LCID fields following this field implying 'the next byte is the start byte of MAC SDU or MAC CE or Padding'.
• iii) LCID : LCID stands for "Logical Channel ID", meaning Logical Channel Number.
• iv) F : F means 'Format'. This defines the length of 'L' field. If F is '0', the length of L field is 7 bit and if F is '1', the length of L field is 15 bit.
• v) F2 : This is new field defined from Release 13. If F2 is '0', the length of L field is determined by F field and if F2 is '1', the length of L field is 16 bit. It means that if F2 is '1', the structure of the header is as (C).
• vi) L : L means 'Length'. It shows the length of the MAC SDU. (Note that some MAC header, labeled as (D) does not have 'L' field. Then how can I know the length of MAC PDU, ie size of MAC PDU ? If there is no 'L' field, the size of MAC PDU is automatically set to be the same size of TBS(transport block size) in Byte unit.

• E decides whether another subheader follows : E = 0 means the payload starts at the next byte.
• F and F2 set the size of L : 7, 15 or 16 bits.
• The last subheader has no L : its SDU takes the rest of the transport block, apart from padding.
• LCID tables differ by direction : 11101 is Timing Advance Command in the downlink and Short BSR in the uplink.

MAC CE - MAC Control Element

A MAC control element is MAC signalling that travels inside a MAC PDU, next to the MAC SDUs. It has no logical channel of its own. Instead, an LCID value reserved for it tells the receiver which control element follows, for example 11101 for a Short BSR in the uplink or 11011 for Activation/Deactivation in the downlink. Some control elements have a fixed size and need no L field, while others carry one.

Refer to MAC CE in Quick Reference

Backoff Indicator - BI

The Backoff Indicator travels in the Random Access Response, not in a DL-SCH data PDU. It uses the E/T/R/R/BI subheader of 36.321 Figure 6.1.5-2 with T set to 0, and it is always the first subheader. Its 4-bit value is an index into 36.321 v19.3.0 Table 7.2-1, from 0 ms at index 0 up to 960 ms at index 12. When a preamble attempt fails, the UE waits a random time between 0 and that value before it tries again.

Refer to Backoff Indicator in Quick Reference

Examples for Good MAC PDU

The examples below take MAC PDUs from trace logs and decode them byte by byte, with the subheader formats above. Each one reads R, R or F2, E and LCID from the first byte, and then follows the E bit until the last subheader. Most are uplink PDUs with a BSR, and the rest are downlink PDUs with a contention resolution or activation MAC CE.

Example 1

Now all these in mind, let's try with my second tip saying "try to anlayze real data by hand". I have the following MAC PDU from my equipment trace log ..

Capture - MAC PDU bytes from the trace log

UL-SCH : 03 45 00 00 3C 33 63 00 00 80 01 00 00 00 00 ....

The first step is to analyze the first byte. For this, let me convert the first byte into binary format as follows :

03 = 00000011

Let's rearrange these bits according to MAC PDU diagram as follows : (Bit number start from MSB meaning "start from left")

* Bit 0 = R field = 0

* Bit 1 = R field = 0

* Bit 2 = E field = 0. This means that this header does not have any other fields following this field and it means 'the next byte is the start byte of MAC SDU or MAC CE or Padding'.

* Bit 3~7 = LCID field = 11 in Binary = 3 in decimal. This means the logical channel number for this PDU is '3'.

This is the end of analysis. All the remaining part is user data.

Example 2

This PDU adds a length field. The first subheader has E = 1, so a second byte follows with F and a 7-bit L, and a padding subheader closes the header. The SDU is on UL CCCH and is 6 bytes long, the size of an RRC Connection Request.

Now let's try with another data as follows :

Capture - MAC PDU bytes from the trace log

UL-SCH : 20 06 1F 5F 09 72 43 FE 56 00 00 00 00 ......

In the same way as above, let's try with the first byte, 20.

20 = 00100000

* Bit 0 = R field = 0

* Bit 1 = R field = 0

* Bit 2 = E field = 1. This means that this header does have some 'Extension' and it means the this MAC PDU has the structure marked as 'A' or 'B' (Figure 6.1.2-1). Then which one is the right one. A ? or B ? The answer comes later. Now the important thing is that you have to decode the second Byte as well since 'E' field is '1'.

* Bit 3~7 = LCID field = 00000 in Binary. This means the logical channel number for this PDU is '00000' which is for UL CCCH (Refer to LCID Field for the meaning of this LCID field).

Since 'E' field is set to '1'. We have to decode the second Byte as well.

06 = 00000110

Bit number continues from from the first byte.

* Bit 8 (bit 0 of the Oct 2) = F field = 0. This means that the size of L field is 7 bit.

* Bit 9~15 (bit 1~bit 7 of the Oct 2)= L field = 0111100 = 06. This means the size of user data in this MAC PDU is 6 byte.

This is the end of second byte analysis. Is this all ? No.. when you have 'E' field to be '1'. You have to continue to decoding the header until you see the end.

Let's continue this analysis to the third byte, 1F as follows :

1F = 00011111

Process start from the begining because we know the first and second byte completes a complete header and I will restart the bit number as well.

* Bit 0 = R field = 0

* Bit 1 = R field = 0

* Bit 2 = E field = 0. It means that it does not have any 'extension'. It does not have any additional header. It means that this is the last header.

* Bit 3~7 = LCID = 11111. What does this mean ? If you see the table 6.2.1-1, 6.2.1-2.. this means 'MAC' padding. It means that this MAC PDU has MAC PDU after the user data. Then exactly which part is the padding and which part is the real user data. If you remember the first/second byte analysis, you should remember the size of real user data is 60 bytes. This, in turn, means that the data after the initial 60 bytes are the MAC padding.

One line in the decode above needs a correction. The second byte 06 is 00000110 in binary, so the L field in bits 9 to 15 is 0000110, not 0111100. The value 6 is still right, and the SDU is the 6 bytes 5F 09 72 43 FE 56.

Example 3

The structure is the same as Example 2, with a different logical channel and a longer SDU. The header is 23 3C 1F, so the SDU on LCID 3 is 60 bytes, and padding fills the rest of the transport block.

Now let's try with another data as follows :

Capture - MAC PDU bytes from the trace log

UL-SCH : 23 3C 1F 45 00 00 3C 33 63 00 00 80 01 00 00 00 00 ......

In the same way as above, let's try with the first byte, 23.

23 = 00100011

* Bit 0 = R field = 0

* Bit 1 = R field = 0

* Bit 2 = E field = 1. This means that this header does have some 'Extension' and it means the this MAC PDU has the structure marked as 'A' or 'B' (Figure 6.1.2-1). Then which one is the right one. A ? or B ? The answer comes later. Now the important thing is that you have to decode the second Byte as well since 'E' field is '1'.

* Bit 3~7 = LCID field = 11 in Binary = 3 in decimal. This means the logical channel number for this PDU is '3'.

Since 'E' field is set to '1'. We have to decode the second Byte as well.

3C = 00111100

Bit number continues from from the first byte.

* Bit 8 (bit 0 of the Oct 2) = F field = 0. This means that the size of L field is 7 bit.

* Bit 9~15 (bit 1~bit 7 of the Oct 2) = L field = 0111100 = 60. This means the size of user data in this MAC PDU is 60 byte.

This is the end of second byte analysis. Is this all ? No.. when you have 'E' field to be '1'. You have to continue to decoding the header until you see the end.

Let's continue this analysis to the third byte, 1F as follows :

1F = 00011111

Process start from the begining because we know the first and second byte completes a complete header and I will restart the bit number as well.

* Bit 0 = R field = 0

* Bit 1 = R field = 0

* Bit 2 = E field = 0. It means that it does not have any 'extension'. It does not have any additional header. It means that this is the last header.

* Bit 3~7 = LCID = 11111. What does this mean ? If you see the table 6.2.1-1, 6.2.1-2.. this means 'MAC' padding. It means that this MAC PDU has MAC PDU after the user data. Then exactly which part is the padding and which part is the real user data. If you remember the first/second byte analysis, you should remember the size of real user data is 60 bytes. This, in turn, means that the data after the initial 60 bytes are the MAC padding.

Example 4

Now let's try with another data as follows : (This time you will see the MAC header is a little bit longer than previous ones. How do I know the MAC header is long ? Big hint is that I count the number of bytes from the start until I hit 1F which is 4 bytes in this case. MAC header does not always end with 1F, but in most case it would be the case)

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

UL-SCH : 3E 21 09 1F 00 00 00 A0 01 01 48 00 60 EB 82 80 00 00 00 00 00 00 00 00 00 00 00 00..

3E = 00111110
R = 0
R = 0
E = 1
LCID = 11110 = Long BSR

21 = 00100001 (LCID is not 1F, not special channel.. it is proper logical channel number.. so the following one or two bytes is part of the same subheader)
R = 0
R = 0
E = 1
LCID = 00001 = Logical Channel #1

09 = 00001001
F = 0
L = 00001001 = 9 Bytes (size of the first SDU. Be careful this is not PDU size)

1F = 00011111

R = 0
R = 0
E = 0
LCID = 11111 = Padding

Long BSR = 00 00 00

Now let's reorganize the above analysis according to the fig 6.1.2-3.

Decode of the MAC PDU above, worked out by hand from the bytes

[Subheader #1]
3E = 00111110
R = 0
R = 0
E = 1
LCID = 11110 = Long BSR

[Subheader #2]
21 09 = 00100001 00001001
R = 0
R = 0
E = 1
LCID = 00001 = Logical Channel #1
F = 0
L = 00001001 = 9 Bytes (size of the first SDU. Be careful this is not PDU size)

[Subheader #3]
1F = 00011111

R = 0
R = 0
E = 0
LCID = 11111 = Padding

[MAC Control element #1]
Long BSR = 00 00 00

[MAC SDU #1]
= 9 bytes
= A0 01 01 48 00 60 EB 82 80

[Padding]
= 00 00 00 00 00 ...

Example 5

Now let's analyze another MAC data. I will summerize the analysis in a little bit short format. If you have difficulties understanding this analysis, try reading < Example 3 > again.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

UL-SCH : 3D 21 27 1F 00 A0 00 00 20 20 00 00 00 26 07 41 01 0B F6 00 00 00 00 00 00 00 00 00 00 02 E0 60 00 05 02 01 D0 11 D0 19 00 00 02 52 00 00 00 00 00 5C 08 02 00 00 00 00 ...

[The detail of MAC header]
3D : MAC subheader #1 ( Short BSR )
R = 0
R = 0
E = 1
LCID = 11101 = Short BSR

21 27 : MAC subheader #2 ( Logical Channel #1 )
R = 0
R = 0
E = 1
LCID = 00001 = Logical Channel #1
F = 0
L = 0100111 = 47 Bytes

1F : MAC subheader #3 ( Padding )
R = 0
R = 0
E = 0
LCID = 11111 = Padding

[MAC Control element #1]
Short BSR = 00

[MAC SDU #1]
= 47 bytes
= A0 00 00 20 20 00 00 00 26 07 41 01 0B F6 00 00 00 00 00 00 00 00 00 00 02 E0 60 00 05 02 01 D0 11 D0 19 00 00 02 52 00 00 00 00 00 5C 08 02

[Padding]
= 00 00 00 00 00 ...

Check the L field of this example once more. 0x27 is 0100111 in binary, which is 39, not 47. So by the header, the SDU is the 39 bytes from A0 up to the byte 52, and the next 8 bytes fall under the padding subheader. The SDU listed above has 47 bytes, so the listing and the L field disagree.

Example 6

This would be a special example which shows you that multiple MAC SDU are combined into a single MAC PDU. This example came from the signaling message "RRC Connection Reconfiguration + Attach Complete".

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

UL-SCH : 3D 21 09 22 11 1F 00 A0 04 04 10 00 40 EB C0 14 A0 00 00 48 00 E0 E8 60 00 6A 40 18 40 00 00 00 00 00 00 00 00 00 00 00 00...

3D : MAC subheader #1 ( Short BSR )
R = 0
R = 0
E = 1
LCID = 11101 = Short BSR


21 09 : MAC subheader #2 ( Logical Channel #1 )
R = 0
R = 0
E = 1
LCID = 00001 = Logical Channel #1

F = 0
L = 0001001 = 9 Bytes

22 11 : MAC subheader #3 ( Logical Channel #2 )
R = 0
R = 0
E = 1
LCID = 00010 = Logical Channel #2

F = 0
L = 0010001 = 17 Bytes

1F : MAC subheader #3 ( Padding )
R = 0
R = 0
E = 0
LCID = 11111 = Padding


[MAC Control element #1]

Short BSR = 00

[MAC SDU #1]

= 9 bytes
= A0 04 04 10 00 40 EB C0 14

[MAC SDU #1]

= 17 bytes
= A0 00 00 48 00 E0 E8 60 00 6A 40 18 40 00 00 00 00

[Padding]

= 00 00 00 00 00 ...

The decode above has two labelling slips. The padding subheader is the fourth subheader, although it is labelled #3. The 17-byte block is MAC SDU #2, although it is labelled #1. The bytes and the field values are correct.

Example 7

A downlink PDU can have a header of one byte. Here the only subheader is also the last one, so it carries no L field, and the SDU takes the whole transport block.

Let me give you another example. This is a MAC data for an IP packet going through DTCH.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

DL-SCH : 03 18 04 50 9A C2 BC 25 C2 F0 BB 0B A0 B6 82 F0 9A 50 97 09 70 BC 26 94 2F 0A B0 BA 0B C2 F0 BC 2F 09 3A 09 27 09 A5 0B C2 69 42 DA 09 70 AE 82 4E 82 DA 0A B0 B7 0B 50 BC 2B A0 9A 4C 2D 42 75 0A B0 BC 2E C2 4D 42 F0 BC 2F 09 70 BC 26 94 2F 09 70 BC 25 C2 BC 2A 4C 2F 0A B0 BC 2F 0B 68 2F 0A B0 AB 09 A5 0B C2 DA 0B C2 F0 BC 2E C2 D4 2F 0B C2 AC 2A C2 47 00 44 14 F0 B6 82 F0 BC 25 C2 BA 0A B0 BC 2F 0B C2 5C 2D A0 BC 2F 0B A0 BC 2F 0B 68 2D A0 BC 26 94 24 E8 25 C2 F0 BC 2F 0A E8 25 C2 F0 BC 2D A0 B5 0B C2 F0 BC 2F 0B C2 5C 2D 42 F0 9D 30 BC 2E C2 D4 2F 0B C2 F0 BC 2E C2 D4 25 C2 69 42 F0 BC 2F 0B C2 F0 9A 50 BC 2F 0A B0 BC 2A C2 F0 BC 2F 0B C2 F0 AB 09 A5 0B 68 2F 0B C2

03 : MAC Header

R = 0
R = 0
E = 0
LCID = 3

This one has only one byte MAC header and it has only LCID and no other information. Then how do you know the size of the data ? This header does not have any size information. It means that all the data except the header part is a single SDU.

Example 8 - Contention Resolution PDU

Msg4 of the random access procedure often carries only the UE Contention Resolution Identity. That MAC control element has a fixed size of 6 bytes, so a single subheader byte describes the whole PDU.

Following is one example of Contention Resolution message during the initial registration.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

DL-SCH : 1C 50 00 00 00 00 07

1C : MAC Header

R = 0
R = 0
E = 0
LCID = 11100 = 1C = It means "This is MAC Header for Contention Resolution".

Since length of Contention Resolution is fixed to be 6 bytes (Refer to 36.321 6.1.3.4). This MAC header does not need to contain any additional F/L field. But there is one thing you have to care about. If the TBS size you allocated for PHY layer is exactly 56 bits, this is good enough. But if the TBS size is greater than 56, you have to add 'Padding' subheader, meaning the header should be like 3C 1F and the whole MAC PDU would be like 50 00 00 00 00 07 00 00 ..

Decode of the MAC PDU above, worked out by hand from the bytes

[MAC SDU]

= 6 bytes
= 50 00 00 00 00 07

The 6 bytes after the header are not a MAC SDU. LCID 11100 identifies the UE Contention Resolution Identity MAC control element, so the block labelled [MAC SDU] above is that control element. It repeats the first 48 bits of the UL CCCH SDU that the UE sent in Msg3.

Example 9

This uplink PDU has the same shape as Example 5: a Short BSR, one SDU and padding. The difference is the logical channel. LCID 2 is SRB2 by default, and the L field 0x17 gives 23 bytes.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

3D 22 17 1F 00 A0 00 00 48 01 A4 E0 00 00 00 00 20 E8 60 00 6A 40 18 40 00 00 00 00 00 00 00 00 00

3D : MAC subheader #1 ( Short BSR )
R = 0
R = 0
E = 1
LCID = 11101 = Short BSR

22 17 : MAC subheader #2
R = 0
R = 0
E = 1
LCID = 00010 = 2
F = 0
L = 010111 = 23 Bytes

1F : MAC subheader #3 ( Padding )
R = 0
R = 0
E = 0
LCID = 11111 = Padding

[MAC Control element #1]
Short BSR = 00

[MAC SDU #1]
= 23 bytes
= A0 00 00 48 01 A4 E0 00 00 00 00 20 E8 60 00 6A 40 18 40 00 00 00 00

Example 10

This would be a special example which shows you that multiple MAC SDU are combined into a single MAC PDU. This example came from the signaling message "MAC Contention Resolution + RRC Connection Setup".

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

DL-SCH : 3C 20 12 1F 00 40 10 00 00 00 60 12 9B 3E 86 0F B5 79 E8 96 6C 30 64 99 60 2C 78 00 00 ...

3C : MAC subheader #1 ( Contention Resolution )
R = 0
R = 0
E = 1
LCID = 11100 = UE Contention Resolution Identity


20 12 : MAC subheader #2 ( CCCH )

R = 0
R = 0
E = 1
LCID = 00000 = CCCH

F = 0
L = 0010010 = 18 Bytes


1F : MAC subheader #3 ( Padding )

R = 0
R = 0
E = 0
LCID = 11111 = Padding


[MAC Control element #1]

UE Contention Resolution Identity = 00 40 10 00 00 00 (6 Bytes fixed)


[MAC SDU #1]

= 18 bytes
= 60 12 9B 3E 86 0F B5 79 E8 96 6C 30 64 99 60 2C 78 00


[Padding]

= 00  ...

Example 11

MAC control elements also appear in the downlink without any SDU. This PDU activates a secondary cell after carrier aggregation is configured, and it needs only a subheader, a padding subheader and one payload byte.

This is an example of MAC CE shown at step (7) of Closer view on Carrier Aggregation Establishment - 2CC.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

DL-SCH : 3B 1F 02 00 00 ...

3B : MAC subheader #1 ( MAC-CE : Activation / Deactivation )
R=0
F2=0
E=1
LCID = 11011 (MAC CE-Activation/Deactivation)

1F = 00011111 : Subheader #2]

R = 0
R = 0
E = 0
LCID = 11111 = Padding

02 : Payload - MAC CE( MAC-CE : Activation / Deactivation )
C7 = 0
C6 = 0
C5 = 0
C4 = 0
C3 = 0
C2 = 0
C1 = 1
R = 0

NOTE : Refer to MAC CE(Activation/Deactivation) page for the details

• Follow the E bit : E = 1 means another subheader, and E = 0 means the payload starts next.
• Convert L carefully : 0x27 is 39, and an error here moves every byte boundary after it.
• Fixed-size MAC CEs have no L : Short BSR is 1 byte, Long BSR 3 bytes, UE Contention Resolution Identity 6 bytes.
• The last subheader has no L : the last SDU takes what remains, unless a padding subheader follows it.

Examples for Bad MAC PDU

A bad MAC PDU in this section is one that the receiver can still parse, but that does not deliver what the sender intended. The receiver trusts the header, whatever the payload holds, so one wrong subheader is enough to lose or corrupt an SDU.

Now let's go through some example of bad cases. In some way, the examples of bad cases would give you more help for troubleshooting.

Example 1 : Bad Case

A PDU can follow the format and still lose data. Here the UE sends a Long BSR and a padding subheader, but no subheader for the SDU it meant to send.

Capture - MAC PDU bytes from the trace log, followed by the header decoded by hand

UL-SCH : 3E 1F 00 00 00 A0 01 01 48 00 60 EB 82 80 07 41 01 0B 00 00 00 00..

[Subheader #1]
3E = 00111110
R = 0
R = 0
E = 1
LCID = 11110 = Long BSR

[Subheader #2]
1F = 00011111

R = 0
R = 0
E = 0
LCID = 11111 = Padding

[MAC Control element #1]
Long BSR = 00 00 00

You see that there no subheader for normal MAC data (MAC SDU).  In this case, all the payload (A0 01 01 48 00 60 EB 82 80 07 41 01 0B) coming after Long BSR is regarded as a MAC padding. So they are discarded and does not go up to higher layer.

Example 2 : Bad Case

This case may or may not cause any problem depending on higher layer implementation on network side. But I take this as a bad case

Capture - MAC PDU bytes from the trace log

UL-SCH : 3D 21 33 1F 00 A0 00 00 20 20 00 00 00 26 07 41 01 0B F6 00 00 00 00 00 00 00 00 00 00 02 E0 60 00 05 02 01 D0 11 D0 19 00 00 02 52 00 00 00 00 00 5C 08 02 00 00 00 00 00 00 ..

Following is the analysis of the header part

Decode of the MAC PDU above, worked out by hand from the bytes

3D : MAC subheader #1 ( Short BSR )
R = 0
R = 0
E = 1
LCID = 11110 = Long BSR

21 33 : MAC subheader #2 ( Logical Channel #1 )
R = 0
R = 0
E = 1
LCID = 00001 = Logical Channel #1
F = 0
L = 0110011 = 51 Bytes (This seems to be MAC PDU size, not SDU size.. this value MAY cause some problem)

1F : MAC subheader #3 ( Padding )
R = 0
R = 0
E = 0
LCID = 11111 = Padding

00 : MAC Control Element #1(Short BSR)

MAC SDU #1 (51 Bytes)
= A0 00 00 20 20 00 00 00 26 07 41 01 0B F6 00 00 00 00 00 00 00 00 00 00 02 E0 60 00 05 02 01 D0 11 D0 19 00 00 02 52 00 00 00 00 00 5C 08 02 00 00 00 00 00

In this case, there would be no problem for the MAC Data (PDU) to go through to the higher layer, but it carries 5 additional trailing 0s. If the higher layer (RRC/NAS) on Network side can properly ignore (chop off) these trailing bytes there would be no problem, but the higher layer complain about this, this incorrect SDU size would cause problem.

One label in the decode above is inconsistent. The first subheader 3D is 00111101, so its LCID is 11101, the Short BSR, as the heading line says. The line LCID = 11110 = Long BSR belongs to 3E, not 3D. The single byte 00 after the header confirms a Short BSR, because a Long BSR takes three bytes.

• A missing subheader turns data into padding : the receiver discards everything after the last subheader.
• A wrong L moves the SDU boundary : the higher layer then receives extra bytes or loses some.

DRX - Discontinous Reception

DRX is a MAC procedure as well. In each subframe, the MAC entity decides whether the UE monitors PDCCH, using the onDurationTimer, the drx-InactivityTimer, the retransmission timers and the long and short DRX cycles that RRC configures. The DRX Command and Long DRX Command MAC control elements, LCID 11110 and 11010 in the DL-SCH table, let the eNB end the active time early.

Refer to DRX page.

Reference

• 3GPP TS 36.321 v19.3.0 - E-UTRA MAC protocol specification. Clause 6.1.2 and 6.1.5 MAC PDU formats, Table 6.2.1-1 and 6.2.1-2 LCID values, Table 7.2-1 Backoff Parameter values