/*Not sure if phy parameters should be initial here or not*/
/*the phy_config_mib_eNB as the entry point to allocate the context for L1. The RC contains the context for L1,L2. If RC.eNB is NULL, it hasn't been allocated earlier so we allocate it there.*/
...
...
@@ -78,7 +83,7 @@ void NB_phy_config_mib_eNB(
fp = &RC.eNB[Mod_id][CC_id]->frame_parms; */
NB_DL_FRAME_PARMS*fp=&PHY_vars_eNB_g[Mod_id][CC_id]->frame_parms;//MP: PHY_VARS_eNB still to be modified
fp->operating_mode=operating_mode;//see how are defined by FAPI structure
fp->NB_IoT_RB_ID=prb_index;//XXX to be better understand how should be managed
//fp->nb_rx_antenna_ports_eNB
//fp->prb_index (applicable only in guard band or in-band operating mode) indicates the prb index with regard to the middle prb in LTE system / delivered by MIB-NB
//fp->eutraControlRegionSize (only if in-band operating mode)
//fp->nb_CRS_ports (valid only for in-band operating mode with different PCI)
fp->control_region_size=control_region_size;//(assume that this value is negative if not used)
fp->eutra_NumCRS_ports=eutra_NumCRS_ports//(valid only for in-band operating mode with different PCI)
* 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
*
*/
NB_IoT_eNB_NPBCHnpbch;
NB_IoT_eNB_NPDCCH_t*npdcch[NUMBER_OF_UE_MAX_NB_IoT];//check the max size of this array
// After stored the Upink information, process it and made it into FAPI style, also provide a tick to the scheduler
// After stored the Upink information, process it and made it into FAPI style, send the UL_Indication to higher layer that also provide a tick to the scheduler
