LTE MAC Layer TB size

1,530 views
Skip to first unread message

Koray Kokten

unread,
Sep 3, 2013, 1:32:37 AM9/3/13
to ns-3-...@googlegroups.com
Hi Everyone,
I have a question about LTE MAC layer implementation. Let me start my question by first giving some numbers from the LTE specification of document TS 36.213 as well as my simulation parameters which are mostly the default parameters of LTE module. In that specification document we are informed about calculating how much resource (in terms of bits) is going to be assigned to a UE under the specific Modulation and Coding Scheme value as well as Resource block number, assigned to it. for a specific time interval. For example in my simulation testbed, I have only one EnB and one UE device that are pretty close to each other (~50m and they are both stable). Also, my bandwidth is 5Mhz which is the default value. In other words, I have 25 Resource blocks that are fully going to be assigned to only one existing UE. Under these parameters I expect from ns-3 to generate a MAC DL trace file where the MCS value is at its maximum (max value is 28) as well as the corresponding TBsize value is at maximum too, under condition where the RB= 25. When I check the DL MAC trace file I see that my MSC value is 28 (which is good), but when I look at the corresponding TB size value I see that it is 2196 while It was supposed to be 18336 according to Table 7.1.7.2.1-1 of TS 36.213.  So that difference does not make sense to me at all. And I don't have any idea about how this values is calculated. More interestingly, that value does not exist at any place of the table though. So my question is, is there anyone out there, who has an idea about how this TB size value is calculated for the UEs.
Thanks in advance,
Best,
   Koray

Marco Miozzo

unread,
Sep 3, 2013, 6:30:02 AM9/3/13
to ns-3-...@googlegroups.com
Hi Koray,

The schedulers uses Type I allocation and allocates 12 resource block groups (RBGs ) which corresponds to 24 RBs (see table 7.1.6.1-1 of 36.213). Therefore, with  MCS 28 it implies 17568 bit -> 2196 bytes according to table 7.1.7.2.1-1 of TS 36.213
I hope this clarify your doubts.

Best regards,
marco.




--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/groups/opt_out.

Koray Kokten

unread,
Sep 3, 2013, 1:07:03 PM9/3/13
to ns-3-...@googlegroups.com
Marco,
Thanks so much for the clear explanation. I just checked the table you referenced. Look like my main confusion is because I thought the DL MAC Transport Block size trace values were in terms of bits rather than bytes in the first time, probably since because the TB Size table (Table 7.1.7.2.1-1) gives the corresponding values in terms of bits.
Thanks again,
Best,
  Koray

Marco Miozzo

unread,
Sep 4, 2013, 3:38:07 AM9/4/13
to ns-3-...@googlegroups.com
Hi,

I know, FF-API is usual to uses bytes while 3GPP docs on PHY/MAC layers are usuals to use bit and this might generate some confusion.

Best regards,
marco.

newns3user

unread,
Feb 12, 2016, 1:10:05 PM2/12/16
to ns-3-users

hi i am sorry to reply an old topic but maybe someone will answer.
I have noticed that using RB = 25 when MCS = 28 for DL i have TBsize = 2196, but this value corresponds to RB=24 referring to Table 7.1.7.2.1-1 ( marco said it is due to the schedulers uses Type I allocation and allocates 12 resource block groups (RBGs ) which corresponds to 24 RBs ).
However,  in UlMacStats.txt when MCS = 28 there is TBsize = 2292 that is the corresponding value for RB = 25 referring to to Table 7.1.7.2.1-1.
I use RB=25 both in Uplink and Downlink. Can you tell me why there is this difference in the TBsize for DL and UL. Of course this difference of TBsize is for every MCS value.
i noticed this because i was interested in calculate the bit-rate at MAC level but doing so i noticed that with this implementation i have a bit-rate in Downlink that is referred to RB= 24 and for UL to RB=25.
Maybe I am having confusion. Please help me to understand where i am wrong.

Biljana Bojović

unread,
Feb 16, 2016, 6:42:27 PM2/16/16
to ns-3-users
Hi,
the transport block size will not only depend on the MCS, but also on the number of RBs assigned to the UE. RBs in UL/DL are assigned, respectively, by the UL/DL MAC scheduling algorithm, and these may be different. So, RBs are not necessarily assigned in the same way. There are several schedulers implemented, which basically differ in DL scheduling, while having the same UL scheduling logic. Scheduler being used can be configured in the simulation program. Check attributes of LteHelper.  Also, you may find more information here: https://www.nsnam.org/docs/models/html/lte-design.html#mac.

Jayway Liu

unread,
Apr 5, 2017, 3:46:55 PM4/5/17
to ns-3-users
I printed out some variables in pf-ff-mac-scheduler.cc, it seems it is exactly like what you said.
However, there is one thing I can not understand. I used ns3-dce and iperf to generate the udp goodput.
The udp goodput I can get with the best channel condition is similar or even higher than 17568 * 1000 = 17.568Mbps. 
I was thinking the 17568bits will also carry all the control channel messages, and all the overheads from various layers. 
So, I am wondering why it is like that. 

For example, I can get 18.0552bps with a loss rate of 9.387%.

Is it related to this thread


why the  number of TB's received each TTI is 2 ? This is different from the 3GPP definition? 

Jayway Liu

unread,
Apr 5, 2017, 3:57:19 PM4/5/17
to ns-3-users
it seems it is not the same as 

https://groups.google.com/forum/#!msg/ns-3-users/-K9RYR61JLo/gM4NzNXqAgAJ;context-place=forum/ns-3-users

before they are using 2x2 MIMO, while I did not. 

I printed out the same variable m_expectedTbs.size (), it is 1. 

Hope someone can help on this problem.  Thanks in advance. 
Reply all
Reply to author
Forward
0 new messages