Notes
A MAC PDU is a bit
string that is byte aligned (i.e. multiple of 8 bits) in length. Similarly, MAC
SDUs are bit strings that are byte aligned (i.e. multiple of 8 bits) in length.
A MAC PDU consists of a MAC header, zero or more MAC SDUs, zero, or more MAC control elements (MAC CE), and optionally padding.
A MAC PDU consists of a MAC header, zero or more MAC SDUs, zero, or more MAC control elements (MAC CE), and optionally padding.
Both the MAC header
and the MAC SDUs are of variable sizes.
A MAC PDU header
consists of one or more MAC PDU subheaders; each subheader corresponds to a MAC
SDU, a MAC CE or padding.
MAC control elements
are always placed before any MAC SDU.
Padding occurs at the
end of the MAC PDU, except when single-byte or two-byte padding is required.
Padding may have any value and the UE shall ignore it. When padding is
performed at the end of the MAC PDU, zero or more padding bytes are allowed.
When single-byte or
two-byte padding is required, one or two MAC PDU subheaders corresponding to
padding are placed at the beginning of the MAC PDU before any other MAC PDU
subheader.
Limitations of this
Decoder:
1. Extended
PHR and MCH Scheduling Information MAC CEs are not yet supported.
Reference:
3GPP TS 36.321
This comment has been removed by the author.
ReplyDeleteAwesome !! Thanks for the great job
ReplyDeleteHi Kumar,
ReplyDeleteWhy is that single-two byte padding header is placed at the beginning ?
Thanks
This comment has been removed by the author.
DeleteNOTE:
Delete1) MAC understands, last subheader is of logical channel, No need to specify the length field for that subheader.
2) MAC understands, that with no need of length field for padding subheader even if it is not a last subheader.
Considering above NOTE: if 1 or 2 byte remaining, if you add padding subheader in last then length field for the previous subheader it cost extra byte, So it is optimal to put the Padding header at begainning.
Sorry for the very delayed response.
Delete36.321: A MAC PDU subheader consists of the five or six header fields R/F2/E/LCID/(F)/L but for the last subheader in the MAC PDU and for fixed sized MAC control elements. 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.
Example:
Let us say that the UE has UL grant of 63 bytes and RLC data is only 61 bytes. Let us consider the following 3 cases
1. Send MAC PDU without Padding: To do this, only one MAC subheader is sufficient and based on the above spec excerpt, the last (only) subheader can only be of type R/F2/E/LCID. So the UE can only have 62 bytes (1 byte subheader + 61 bytes of data)
2. Send MAC PDU with Padding at the end: As the MAC PDU has more than one subheaders and padding is the last subheader, it is necessary to include two byte header field for data (R/F2/E/LCID/F/L sub-header with 7-bits L field). This method needs total of 64 bytes(2-byte subheader for LCH data + 1-byte subheader for Padding + 61 bytes of data)
3. Send MAC PDU with Padding at the beginning: In this case data beging last subheader it only requires one byte (R/F2/E/LCID) - This requires a total of 63 bytes.(1-byte padding at the beginning + 1-byte MAC subheader for LCH data + 61 bytes of data)
I hope it is clear now why the padding is used at the beginning.
This comment has been removed by the author.
ReplyDeleteI want to know about implicit release of SPS in which if certain number of MAC PDUs have zero MAC SDUs then SPS releases. So is it possible to make a MAC PDU with zero MAC SDU and none Control Element. If yes, how? Can you give any example?
ReplyDeleteyou need to update the release version it looks like the tool is still on release 9
ReplyDelete