// common_signal_procedures_NB_IoT(eNB,proc); // to uncomment after NB-IoT testing
//Generate MIB
if(subframe==0&&(eNB->npbch!=NULL))
{
if(eNB->npbch->pdu!=NULL)
{
//BCOM function
/*
* -the function get the MIB pdu and schedule the transmission over the 64 radio frame
* -need to check the subframe #0 (since encoding functions only check the frame)
* this functions should be called every frame (the function will transmit the remaining part of MIB)
* ( XXX Should check when the schedule_responce is transmitted by MAC scheduler)
* RB-ID only for the case of in-band operation but should be always considered
* (in stand alone i can put whatever the number)in other case consider the PRB index in the Table R&Shwartz pag 9
*
*/
/*
generate_npbch(eNB->npbch,
txdataF,
AMP,
fp,
eNB->npbch->pdu,
frame%64,
fp->NB_IoT_RB_ID);*/
}
//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
/*
*
* the function should be called for each frame
* Parameters needed:
* -sib1-NB pdu if new one (should be given by the MAC at the start of each SIB1-NB period)
* -when start a new SIB1-NB repetition (sib1_rep_start)
* -the frame number relative to the 16 continuous frame within a repetition (relative_sib1_frame) 1st, 2nd ...
*
* we check that the transmission should occurr in subframe #4
*
* 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 (pdu = NULL)
eNB->ndlsch_SIB1,//since we have no DCI for system information, this is filled directly when we receive the NDLSCH pdu from DL_CONFIG.request message
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 next SIB1-NB transmission
if((frame-sib1_startFrame)%256==255)
{
//whenever we will not receive a new sdu from MAC at the start of the next SIB1-NB period we prevent future SIB1-NB transmission (may just only of the two condition is necessary)
eNB->ndlsch_SIB1->harq_process->status=DISABLED;
eNB->ndlsch_SIB1->harq_process->pdu=NULL;
}
}
//Check for SI transmission
/*
*Parameters needed:
* -total number of subframes for the transmission (2-8) (inside the NDLSCH structure --> HARQ process -->resource_assignment)
* XXX: in reality this flag is not needed because is enough to check if the PDU is NULL (continue the transmission) or not (new SI transmission)
* -SI_start (inside ndlsch structure): flag for indicate the starting of the SI transmission within the SI window (new PDU is received by the MAC) otherwise the PHY continue to transmit
* what have in its buffer (so check the remaining encoded data continuously)
*
* SI transmission should not occurr in reserved subframes
* subframe = 0 (MIB-NB)
* subframe = 4 (SIB1-NB) but depends on the frame
* subframe = 5 (NPSS)
* subframe = 9 (NSSS) but depends on the frame (if is even)
*
* [This condition should be known by the MAC layer so it should trigger an DLSCH pdu only at proper instants]
*
* XXX Important: in the case the SI-window finish the PHY layer should have also being able to conclude all the SI transmission in time
* (because this is managed by the MAC layer that stops transmitting the SDU to PHY in advance because is counting the remaining subframe for the transmission)
*
*
*XXX important: set the flag HARQ process->status to DISABLE when PHY finished the SI-transmission over the 2 or 8 subframes
*XXX important: whenever we enter for some error in the ndlsch_procedure with a pdu that is NULL but all the data of the SI have been transmitted (pdu_buffer_index = 0)
*XXX --> generate error
*XXX: the npdlsch_procedure in this case should be only called when is triggered by the MAC schedule_response (use the status flag set by the schedule_response)
*
*/
if(eNB->ndlsch_SI->harq_process->status==ACTIVE_NB_IoT&&(eNB->ndlsch_SIB1->harq_process->status!=ACTIVE_NB_IoT||subframe!=4))//condition on SIB1-NB
{
if(frame%2==0)//condition on NSSS (subframe 9 not available)
eNB->ndlsch_ra,//should be filled ?? (in the old implementation was filled when from DCI we generate_dlsch_params
eNB->ndlsch_ra->harq_process->pdu);
//it should be activated only when we receive the proper DCIN1_RAR
eNB->ndlsch_ra->active=0;// maybe this is already done inside the ndlsch_procedure
}
}
}
//check for UE specific transmission
/*
* Delays between DCI transmission and NDLSCH transmission are taken in consideration by the MAC scheduler by sending in the proper subframe the scheduler_response
* (TS 36.213 ch 16.4.1: DCI format N1, N2, ending in subframe n intended for the UE, the UE shall decode, starting from subframe n+5 DL subframe,
* the corresponding NPDSCH transmission over the N consecutive NB/IoT DL subframes according to NPDCCH information)
* Transmission over more subframe and Repetitions are managed directly by the PHY layer
* We should have only 1 ue-specific ndlsch structure active at each time (active flag is set = 1 only at the corresponding NDLSCH pdu reception and not at the DCI time
* (NDLSCH transmission should be compliant with the FAPI procedure Figure 3-49)
*
* XXX how are managed the transmission and repetitions over the NPDSCH:
* -repetitions over the NPDSCH channel are defined inside the DCI
* -need to know the repetition number R (see specs)
* -repetition are made following a pattern rule (e.g. 00, 11 ...) (see specs)
* --whenever R>4 then repetition pattern rule changes
* -possibility to have DL-GAP (OPTIONAL) otherwise no gap in DCI transmission
*
* XXX During repetitions of DCI or NDLSCH we receive no schedule_response form MAC
*
*/
//this should give only 1 result (since only 1 ndlsch procedure is activated at once) so we brak after the transmission
if(eNB->ndlsch[(uint8_t)UE_id]!=NULL&&eNB->ndlsch[(uint8_t)UE_id]->active==1&&(eNB->ndlsch_SIB1->harq_process->status!=ACTIVE_NB_IoT||subframe!=4))//condition on sib1-NB
{
if(frame%2==0)//condition on NSSS (subframe 9 not available)
{
if(subframe!=0&&subframe!=5&&subframe!=9)
{
npdsch_procedures(eNB,
proc,
eNB->ndlsch[(uint8_t)UE_id],
eNB->ndlsch[(uint8_t)UE_id]->harq_process->pdu);
break;
}
}
else//this frame not foresee the transmission of NSSS (subframe 9 is available)
{
if(subframe!=0&&subframe!=5)
{
npdsch_procedures(eNB,
proc,
eNB->ndlsch[(uint8_t)UE_id],
eNB->ndlsch[(uint8_t)UE_id]->harq_process->pdu);
break;
}
}
}
}
//no dedicated phy config
/*If we have DCI to generate do it now
*
* DCI in NB-IoT are transmitted over NPDCCH search spaces as described in TS 36.213 ch 16.6
*
* Don-t care about the concept of search space since will be managed by the MAC.
* MAC also evaluate the starting position of NPDCCH transmission and will send the corresponding scheduling_response
*
*
* The PHY layer should evaluate R (repetitions of DCI) based on:
* -L (aggregation level) --> inside the NPDCCH PDU
* -Rmax
* -DCI subframe repetition number (2 bits) --> inside the NPDCCH PDU
* -TS 36.213 Table 16.6/1/2/3
*
*
* The higher layer parms (Rmax):
* -npdcch-NumRepetitions (UE-specific) [inside the NPDCCH UE-specific strucuture] --> configured through phyconfigDedicated
* -npdcch-NumRepetitionPaging (common)
* -npdcch-NumRepetitions-RA (common) [inside the NB_IoT_DL_FRAME_PARMS-> nprach_ParametersList] --> configured in phy_config_sib2
*
* PROBLEM: in FAPI specs seems there is no way to trasnmit Rmax to the PHY (waiting for answers)
*
* *Rmax is also needed for evaluate the scheduling delay for NDLSCH (see scheduling delay field in NPDCCH PDU FAPI)
*
* *Scrambling re-initialization is needed at the beginning of the Search Space or every 4th NPDCCH subframe (See TS 36.211)
* (this is taken in cosideration by the NPDCCH parameter "scrambling re-initialization batch index" in FAPI specs (Table 4-45)
*
****whenever we have aggregation level = 1 for UE-specific the R is always = 1 (see table 16.6-1)
****DCI DL transmission should not happen in case of reference signals or SI messages (this function should be triggered every subframe)
eNB->UL_INFO.nrach_ind.number_of_initial_scs_detected=1;//!!!!!!!!!!!!! // should be set to zero in every call of UL_indication !!!!!!!!!!!!!!!!!!!!!!!
