ndlsch_harq->repetition_number=rel13->repetition_number;//is the schedulingInfoSIB1 of MMIB that is mapped into value 4-8-16 (see NDLSCH fapi specs Table 4-47)
ndlsch_harq->modulation=rel13->modulation;
ndlsch_harq->status=ACTIVE;
//SI information in reality have no feedback
//SI information in reality have no feedback (so there is no retransmission from the HARQ view point since no sck and nack)
if(eNB->abstraction_flag==0){// used for simulation of the PHY??
/*
* in any case inside the encoding procedure is re-checked if this is round 0 or no
* in the case of harq_process round = 0 --> generate the sequence and put it into the parameter *c[r]
* otherwise do nothing(only rate maching)
*/
/*
* REASONING:
* Encoding procedure will generate a Table with encoded data ( in ndlsch structure)
* The table will go in input to the scrambling
* --we should take care if there are repetitions of data or not because scrambling should be called at the first frame and subframe in which each repetition
r_type, rn is only used in PMCH procedure so I remove it.
*/
* ASSUMPTION
*Since in FAPI specs seems to not manage the information for the sceduling of system information:
* Assume that the MAC layer manage the scheduling for the System information (SI messages) transmission while MIB and SIB1 are done directly at PHY layer
* This means that the MAC scheduler will send to the PHY the NDLSCH PDU and MIB PDU (DL_CONFIG.request)each time they should be transmitted. In particular:
***MIB-NB
*schedule_response containing a n-BCH PDU is transmitted only at the beginning of the MIB period, then repetitions are made directly by the PHY layer (see FAPI specs pag 94 N-BCH 3.2.4.2)
*if no new N-BCH PDU is trasmitted at SFN mod 64=0 then stop MIB transmission
***SIB1-NB
*schedule response containing a NDLSCH pdu (with appropiate configuration) will be transmitted only at the beginning of each SIB1-NB period (256 rf)
*then repetitions are managed directly by the PHY layer
*if no new NDLSCH pdu (configured for SIB1-NB) at SFN mod 256 = 0 is transmitted. stop SIB1-NB transmission
****SI Messages
* -schedule_response is transmitted by the MAC in every subframe needed for the SI transmission (NDLSCH should have a proper configuration)
* -if the schedule_response carry any SDU (SDU!= NULL)--> put the SDU in the PHY buffer to be encoded ecc... and start the transmission
* -if the schedule_response not carry any SDU (SDU == NULL) but NDLSCH is properly set for SI, then PHY continue transmit the remaining part of the previous SDU
* (this because the PHY layer have no logic of repetition_pattern, si_window ecc.. so should be continuously instructed the PHY when to transmit.
* Furthermore, SI messages are transmitted in more that 1 subframe (2 or 8) and therefore MAC layer need to count how many subframes are available in the current frame for transmit it
* and take in consideration that other frames are needed before starting the transmission of a new one)
*
*
* FAPI distingsh the BCCH info in the NDLSCH may for some reasons:
* -scrambling is different
*
* **relevant aspects for the System information Transmission (Table 4-47 NDLSCH FAPi specs)
LOG_E(PHY,"NB_phy_procedures_eNB_TX: missed mib pdu to be transmitted\n");
}
//In the last frame in which the MIB-NB should be transmitted after we point to NULL since maybe we stop MIB trasnmission
//this should be in line with FAPI specs pag 94 (BCH procedure in Downlink 3.2.4.2 for NB-IoT)
if(frame%64==63)
eNB->npbch->pdu=NULL;
}
//Check for SIB1-NB transmission
//we should still consider that if at the start of the new SIB1-NB period the MAC will not send an NPDSCH for the SIB1-NB transmission then SIB1-NB will be not transmitted
eNB->ndlsch_SIB1,//since we have no DCI for system information, this is filled directly when we receive the DL_CONFIG.request message (add a file in Sched_INFO)
eNB->ndlsch_SIB1->harq_process->pdu);
}
//at the end of the period we put the PDU to NULL since we have to wait for the new one from the MAC for starting the nextis_SIB1_NB
if((frame-sib1_startFrame)%256==255)
eNB->ndlsch_SIB1->harq_process->pdu=NULL;
///check for BCCH transmission (System Information)
//XXX the scheduling of SI and also MIB ecc... we don-t care at phy layer??? is the scheduler that gives us the DL_config at proper time??
