* NUMBER_OF_UE_MAX_NB_IoT maybe in the future should be dynamic because could be very large and the memory may explode
* (is almost the indication of the number of UE context that we are storing at PHY layer)
*
* reasoning: the following data structure (ndlsch, nulsch ecc..) are used to store the context that should be transmitted in at least n+4 subframe later
* (the minimum interval between NPUSCH and the ACK for this)
* the problem is that in NB_IoT the ACK for the UPLINK is contained in the DCI through the NDI field (if this value change from the previous one then it means ACK)
* but may we could schedule this DCI long time later so may lots of contents shuld be stored (there is no concept of phich channel in NB-IoT)
* For the DL transmission the UE send a proper ACK/NACK message
*
* *the HARQ process should be killed when the NDI change
*
* *In the Structure for nulsch we should also store the information related to the subframe (because each time we should read it and understand what should be done
* in that subframe)
*
*/
/*
* TIMING
* the entire transmission and scheduling are done for the "subframe" concept but the subframe = proc->subframe_tx (that in reality is the subframe_rx +4)
* (see USER/lte-enb/wakeup_rxtx )
*
* Related to FAPI:
* DCI and DL_CONFIG.request (also more that 1) and MAC_PDU are transmitted in the same subframe (our assumption) so will be all contained in the schedule_response getting from the scheduler
* DCI0 and UL_CONFIG.request are transmitted in the same subframe (our assumption) so contained in the schedule_response
*
*/
//TODO: check what should be NUMBER_OF_UE_MAX_NB_IoT value
