uint32_tpointer_to_sf=SIB23->pointer_to_subframe;/// to identify wich encoded subframe to transmit
intG=get_G_NB_IoT(frame_parms);
uint8_tNsf=SIB23->resource_assignment;//value 2 or 8
if(counter_rep==rep)
{
dlsch_encoding_NB_IoT(SIB23_pdu,
SIB23,
Nsf,///// number_of_subframes_required
G);//// this vallue is fixed, should take into account in future the case of stand-alone & guard-band
dlsch_scrambling_Gen_NB_IoT(frame_parms,
SIB23,
Nsf*G,
frame,
subframe*2,
SIB23->rnti,
release_v13_5_0,
1);
}
dlsch_modulation_NB_IoT(txdataF,
amp,
frame_parms,
eutra_control_region,//should be replace by start_symbole // control region size for LTE , values between 0..3, (0 for stand-alone / 1, 2 or 3 for in-band)
eutra_control_region,//should be replace by start_symbole // control region size for LTE , values between 0..3, (0 for stand-alone / 1, 2 or 3 for in-band)
eutra_control_region,//should be replace by start_symbole // control region size for LTE , values between 0..3, (0 for stand-alone / 1, 2 or 3 for in-band)
dlsch_scrambling_Gen_NB_IoT(fp, // is called only in subframe 4
sib23,
1888, ////// total_bits
frame,
subframe*2,
eNB->ndlsch_SIB23->rnti);
}
if( subframe < 5 )
{
dlsch_modulation_NB_IoT(txdataF,
AMP,
fp,
3, // control region size for LTE , values between 0..3, (0 for stand-alone / 1, 2 or 3 for in-band)
sib23,
236, // number of bits per subframe
(subframe-1), ///npdsch_data_subframe, data per subframe//subframe index of the data table of npdsch channel (G*Nsf) ((frame%32)/2),values are between 0..Nsf
subframe,
RB_IoT_ID);
} else {
dlsch_modulation_NB_IoT(txdataF,
AMP,
fp,
3, // control region size for LTE , values between 0..3, (0 for stand-alone / 1, 2 or 3 for in-band)
sib23,
236, // number of bits per subframe
(subframe-2),///npdsch_data_subframe, data per subframe//subframe index of the data table of npdsch channel (G*Nsf) ((frame%32)/2),values are between 0..Nsf
/// Enumeration for parameter PHICH-Duration \ref PHICH_CONFIG_COMMON::phich_duration.
typedefenum{
normal=0,
extended=1
}PHICH_DURATION_t;
/// Enumeration for parameter Ng \ref PHICH_CONFIG_COMMON::phich_resource.
typedefenum{
oneSixth=1,
half=3,
one=6,
two=12
}PHICH_RESOURCE_t;
#endif
/// PHICH-Config from 36.331 RRC spec
typedefstruct{
/// Parameter: PHICH-Duration, see TS 36.211 (Table 6.9.3-1).
PHICH_DURATION_tphich_duration;
/// Parameter: Ng, see TS 36.211 (6.9). \details Value oneSixth corresponds to 1/6, half corresponds to 1/2 and so on.
PHICH_RESOURCE_tphich_resource;
}PHICH_CONFIG_COMMON;
/// PRACH-ConfigInfo from 36.331 RRC spec
typedefstruct{
/// Parameter: prach-ConfigurationIndex, see TS 36.211 (5.7.1). \vr{[0..63]}
uint8_tprach_ConfigIndex;
/// Parameter: High-speed-flag, see TS 36.211 (5.7.2). \vr{[0..1]} 1 corresponds to Restricted set and 0 to Unrestricted set.
uint8_thighSpeedFlag;
/// Parameter: \f$N_\text{CS}\f$, see TS 36.211 (5.7.2). \vr{[0..15]}\n Refer to table 5.7.2-2 for preamble format 0..3 and to table 5.7.2-3 for preamble format 4.
uint8_tzeroCorrelationZoneConfig;
/// Parameter: prach-FrequencyOffset, see TS 36.211 (5.7.1). \vr{[0..94]}\n For TDD the value range is dependent on the value of \ref prach_ConfigIndex.
uint8_tprach_FreqOffset;
}PRACH_CONFIG_INFO;
/// PRACH-ConfigSIB or PRACH-Config from 36.331 RRC spec
typedefstruct{
/// Parameter: RACH_ROOT_SEQUENCE, see TS 36.211 (5.7.1). \vr{[0..837]}
uint16_trootSequenceIndex;
/// prach_Config_enabled=1 means enabled. \vr{[0..1]}
uint8_tprach_Config_enabled;
/// PRACH Configuration Information
PRACH_CONFIG_INFOprach_ConfigInfo;
}PRACH_CONFIG_COMMON;
#if (LTE_RRC_VERSION >= MAKE_VERSION(14, 0, 0))
/// PRACH-eMTC-Config from 36.331 RRC spec
typedefstruct{
/// Parameter: High-speed-flag, see TS 36.211 (5.7.2). \vr{[0..1]} 1 corresponds to Restricted set and 0 to Unrestricted set.
uint8_thighSpeedFlag;
/// Parameter: \f$N_\text{CS}\f$, see TS 36.211 (5.7.2). \vr{[0..15]}\n Refer to table 5.7.2-2 for preamble format 0..3 and to table 5.7.2-3 for preamble format 4.
uint8_tzeroCorrelationZoneConfig;
/// Parameter: prach-FrequencyOffset, see TS 36.211 (5.7.1). \vr{[0..94]}\n For TDD the value range is dependent on the value of \ref prach_ConfigIndex.
/// PRACH starting subframe periodicity, expressed in number of subframes available for preamble transmission (PRACH opportunities), see TS 36.211. Value 2 corresponds to 2 subframes, 4 corresponds to 4 subframes and so on. EUTRAN configures the PRACH starting subframe periodicity larger than or equal to the Number of PRACH repetitions per attempt for each CE level (numRepetitionPerPreambleAttempt).
uint8_tprach_starting_subframe_periodicity[4];
/// number of repetitions per preamble attempt per CE level
uint8_tprach_numRepetitionPerPreambleAttempt[4];
/// prach configuration index for each CE level
uint8_tprach_ConfigIndex[4];
/// indicator for CE level activation
uint8_tprach_CElevel_enable[4];
/// prach frequency offset for each CE level
uint8_tprach_FreqOffset[4];
/// indicator for CE level hopping activation
uint8_tprach_hopping_enable[4];
/// indicator for CE level hopping activation
uint8_tprach_hopping_offset[4];
}PRACH_eMTC_CONFIG_INFO;
/// PRACH-ConfigSIB or PRACH-Config from 36.331 RRC spec
typedefstruct{
/// Parameter: RACH_ROOT_SEQUENCE, see TS 36.211 (5.7.1). \vr{[0..837]}
uint16_trootSequenceIndex;
/// prach_Config_enabled=1 means enabled. \vr{[0..1]}
uint8_tprach_Config_enabled;
/// PRACH Configuration Information
#if (LTE_RRC_VERSION >= MAKE_VERSION(14, 0, 0))
PRACH_eMTC_CONFIG_INFOprach_ConfigInfo;
#endif
}PRACH_eMTC_CONFIG_COMMON;
#endif
/// Enumeration for parameter \f$N_\text{ANRep}\f$ \ref PUCCH_CONFIG_DEDICATED::repetitionFactor.
typedefenum{
n2=0,
n4,
n6
}ACKNAKREP_t;
/// Enumeration for \ref PUCCH_CONFIG_DEDICATED::tdd_AckNackFeedbackMode.
typedefenum{
bundling=0,
multiplexing
}ANFBmode_t;
/// PUCCH-ConfigDedicated from 36.331 RRC spec
typedefstruct{
/// Flag to indicate ACK NAK repetition activation, see TS 36.213 (10.1). \vr{[0..1]}
uint8_tackNackRepetition;
/// Parameter: \f$N_\text{ANRep}\f$, see TS 36.213 (10.1).
ACKNAKREP_trepetitionFactor;
/// Parameter: \f$n^{(1)}_\text{PUCCH,ANRep}\f$, see TS 36.213 (10.1). \vr{[0..2047]}
uint16_tn1PUCCH_AN_Rep;
/// Feedback mode, see TS 36.213 (7.3). \details Applied to both PUCCH and PUSCH feedback. For TDD, should always be set to bundling.
ANFBmode_ttdd_AckNackFeedbackMode;
}PUCCH_CONFIG_DEDICATED;
/// PUCCH-ConfigCommon from 36.331 RRC spec
typedefstruct{
/// Parameter: \f$\Delta^\text{PUCCH}_\text{shift}\f$, see TS 36.211 (5.4.1). \vr{[1..3]} \note the specification sais it is an enumerated value.
uint8_tdeltaPUCCH_Shift;
/// Parameter: \f$N^{(2)}_\text{RB}\f$, see TS 36.211 (5.4). \vr{[0..98]}
uint8_tnRB_CQI;
/// Parameter: \f$N^{(1)}_\text{CS}\f$, see TS 36.211 (5.4). \vr{[0..7]}
uint8_tnCS_AN;
/// Parameter: \f$N^{(1)}_\text{PUCCH}\f$ see TS 36.213 (10.1). \vr{[0..2047]}
uint16_tn1PUCCH_AN;
/// group hopping sequence for DRS \note not part of offical UL-PUCCH_CONFIG_COMMON ASN1 specification.
uint8_tgrouphop[20];
/// sequence hopping sequence for DRS \note not part of offical UL-PUCCH_CONFIG_COMMON ASN1 specification.
uint8_tseqhop[20];
}PUCCH_CONFIG_COMMON;
/// UL-ReferenceSignalsPUSCH from 36.331 RRC spec
typedefstruct{
/// Parameter: Group-hopping-enabled, see TS 36.211 (5.5.1.3). \vr{[0..1]}
uint8_tgroupHoppingEnabled;
/// Parameter: \f$\Delta SS\f$, see TS 36.211 (5.5.1.3). \vr{[0..29]}
uint8_tgroupAssignmentPUSCH;
/// Parameter: Sequence-hopping-enabled, see TS 36.211 (5.5.1.4). \vr{[0..1]}
uint8_tsequenceHoppingEnabled;
/// Parameter: cyclicShift, see TS 36.211 (Table 5.5.2.1.1-2). \vr{[0..7]}
uint8_tcyclicShift;
/// nPRS for cyclic shift of DRS \note not part of offical UL-ReferenceSignalsPUSCH ASN1 specification.
uint8_tnPRS[20];
/// group hopping sequence for DRS \note not part of offical UL-ReferenceSignalsPUSCH ASN1 specification.
uint8_tgrouphop[20];
/// sequence hopping sequence for DRS \note not part of offical UL-ReferenceSignalsPUSCH ASN1 specification.
uint8_tseqhop[20];
}UL_REFERENCE_SIGNALS_PUSCH_t;
/// Enumeration for parameter Hopping-mode \ref PUSCH_CONFIG_COMMON::hoppingMode.
#ifndef OCP_FRAMEWORK
typedefenum{
interSubFrame=0,
intraAndInterSubFrame=1
}PUSCH_HOPPING_t;
#endif
/// PUSCH-ConfigCommon from 36.331 RRC spec.
typedefstruct{
/// Parameter: \f$N_{sb}\f$, see TS 36.211 (5.3.4). \vr{[1..4]}
uint8_tn_SB;
/// Parameter: Hopping-mode, see TS 36.211 (5.3.4).
PUSCH_HOPPING_thoppingMode;
/// Parameter: \f$N^{HO}_{RB}\f$, see TS 36.211 (5.3.4). \vr{[0..98]}
uint8_tpusch_HoppingOffset;
/// See TS 36.213 (8.6.1). \vr{[0..1]} 1 indicates 64QAM is allowed, 0 not allowed.
/// Parameter: \f$I^\text{HARQ-ACK}_\text{offset}\f$, see TS 36.213 (Table 8.6.3-1). \vr{[0..15]}
uint16_tbetaOffset_ACK_Index;
/// Parameter: \f$I^{RI}_\text{offset}\f$, see TS 36.213 (Table 8.6.3-2). \vr{[0..15]}
uint16_tbetaOffset_RI_Index;
/// Parameter: \f$I^{CQI}_\text{offset}\f$, see TS 36.213 (Table 8.6.3-3). \vr{[0..15]}
uint16_tbetaOffset_CQI_Index;
}PUSCH_CONFIG_DEDICATED;
/// lola CBA information
typedefstruct{
///
uint16_tbetaOffset_CA_Index;
///
uint16_tcShift;
}PUSCH_CA_CONFIG_DEDICATED;
/// PDSCH-ConfigCommon from 36.331 RRC spec
typedefstruct{
/// Parameter: Reference-signal power, see TS 36.213 (5.2). \vr{[-60..50]}\n Provides the downlink reference-signal EPRE. The actual value in dBm.
int8_treferenceSignalPower;
/// Parameter: \f$P_B\f$, see TS 36.213 (Table 5.2-1). \vr{[0..3]}
uint8_tp_b;
}PDSCH_CONFIG_COMMON;
/// Enumeration for Parameter \f$P_A\f$ \ref PDSCH_CONFIG_DEDICATED::p_a.
typedefenum{
dBm6=0,///< (dB-6) corresponds to -6 dB
dBm477,///< (dB-4dot77) corresponds to -4.77 dB
dBm3,///< (dB-3) corresponds to -3 dB
dBm177,///< (dB-1dot77) corresponds to -1.77 dB
dB0,///< corresponds to 0 dB
dB1,///< corresponds to 1 dB
dB2,///< corresponds to 2 dB
dB3///< corresponds to 3 dB
}PA_t;
/// PDSCH-ConfigDedicated from 36.331 RRC spec
typedefstruct{
/// Parameter: \f$P_A\f$, see TS 36.213 (5.2).
PA_tp_a;
}PDSCH_CONFIG_DEDICATED;
/// SoundingRS-UL-ConfigCommon Information Element from 36.331 RRC spec
typedefstruct{
/// enabled flag=1 means SRS is enabled. \vr{[0..1]}
uint8_tenabled_flag;
/// Parameter: SRS Bandwidth Configuration, see TS 36.211 (table 5.5.3.2-1, 5.5.3.2-2, 5.5.3.2-3 and 5.5.3.2-4). \vr{[0..7]}\n Actual configuration depends on UL bandwidth. \note the specification sais it is an enumerated value.
uint8_tsrs_BandwidthConfig;
/// Parameter: SRS SubframeConfiguration, see TS 36.211 (table 5.5.3.3-1 for FDD, table 5.5.3.3-2 for TDD). \vr{[0..15]} \note the specification sais it is an enumerated value.
uint8_tsrs_SubframeConfig;
/// Parameter: Simultaneous-AN-and-SRS, see TS 36.213 (8.2). \vr{[0..1]}
uint8_tackNackSRS_SimultaneousTransmission;
/// Parameter: srsMaxUpPts, see TS 36.211 (5.5.3.2). \details If this field is present, reconfiguration of \f$m^\text{max}_\text{SRS,0}\f$ applies for UpPts, otherwise reconfiguration does not apply.
uint8_tsrs_MaxUpPts;
}SOUNDINGRS_UL_CONFIG_COMMON;
/// \note UNUSED
typedefenum{
ulpc_al0=0,
ulpc_al04=1,
ulpc_al05=2,
ulpc_al06=3,
ulpc_al07=4,
ulpc_al08=5,
ulpc_al09=6,
ulpc_al11=7
}UL_POWER_CONTROL_COMMON_alpha_t;
/// Enumeration for \ref deltaFList_PUCCH_t::deltaF_PUCCH_Format1.
typedefenum{
deltaF_PUCCH_Format1_deltaF_2=0,
deltaF_PUCCH_Format1_deltaF0=1,
deltaF_PUCCH_Format1_deltaF2=2
}deltaF_PUCCH_Format1_t;
/// Enumeration for \ref deltaFList_PUCCH_t::deltaF_PUCCH_Format1b.
typedefenum{
deltaF_PUCCH_Format1b_deltaF1=0,
deltaF_PUCCH_Format1b_deltaF3=1,
deltaF_PUCCH_Format1b_deltaF5=2
}deltaF_PUCCH_Format1b_t;
/// Enumeration for \ref deltaFList_PUCCH_t::deltaF_PUCCH_Format2.
typedefenum{
deltaF_PUCCH_Format2_deltaF_2=0,
deltaF_PUCCH_Format2_deltaF0=1,
deltaF_PUCCH_Format2_deltaF1=2,
deltaF_PUCCH_Format2_deltaF2=3
}deltaF_PUCCH_Format2_t;
/// Enumeration for \ref deltaFList_PUCCH_t::deltaF_PUCCH_Format2a.
typedefenum{
deltaF_PUCCH_Format2a_deltaF_2=0,
deltaF_PUCCH_Format2a_deltaF0=1,
deltaF_PUCCH_Format2a_deltaF2=2
}deltaF_PUCCH_Format2a_t;
/// Enumeration for \ref deltaFList_PUCCH_t::deltaF_PUCCH_Format2b.
typedefenum{
deltaF_PUCCH_Format2b_deltaF_2=0,
deltaF_PUCCH_Format2b_deltaF0=1,
deltaF_PUCCH_Format2b_deltaF2=2
}deltaF_PUCCH_Format2b_t;
/// DeltaFList-PUCCH from 36.331 RRC spec
typedefstruct{
deltaF_PUCCH_Format1_tdeltaF_PUCCH_Format1;
deltaF_PUCCH_Format1b_tdeltaF_PUCCH_Format1b;
deltaF_PUCCH_Format2_tdeltaF_PUCCH_Format2;
deltaF_PUCCH_Format2a_tdeltaF_PUCCH_Format2a;
deltaF_PUCCH_Format2b_tdeltaF_PUCCH_Format2b;
}deltaFList_PUCCH_t;
/// SoundingRS-UL-ConfigDedicated Information Element from 36.331 RRC spec
typedefstruct{
/// This descriptor is active
uint8_tactive;
/// This descriptor's frame
uint16_tframe;
/// This descriptor's subframe
uint8_tsubframe;
/// rnti
uint16_trnti;
/// Parameter: \f$B_\text{SRS}\f$, see TS 36.211 (table 5.5.3.2-1, 5.5.3.2-2, 5.5.3.2-3 and 5.5.3.2-4). \vr{[0..3]} \note the specification sais it is an enumerated value.
uint8_tsrs_Bandwidth;
/// Parameter: SRS hopping bandwidth \f$b_\text{hop}\in\{0,1,2,3\}\f$, see TS 36.211 (5.5.3.2) \vr{[0..3]} \note the specification sais it is an enumerated value.
uint8_tsrs_HoppingBandwidth;
/// Parameter: \f$n_\text{RRC}\f$, see TS 36.211 (5.5.3.2). \vr{[0..23]}
uint8_tfreqDomainPosition;
/// Parameter: Duration, see TS 36.213 (8.2). \vr{[0..1]} 0 corresponds to "single" and 1 to "indefinite".
uint8_tduration;
/// Parameter: \f$k_\text{TC}\in\{0,1\}\f$, see TS 36.211 (5.5.3.2). \vr{[0..1]}
uint8_ttransmissionComb;
/// Parameter: \f$I_\text{SRS}\f$, see TS 36.213 (table 8.2-1). \vr{[0..1023]}
uint16_tsrs_ConfigIndex;
/// Parameter: \f$n^\text{CS}_\text{SRS}\f$. See TS 36.211 (5.5.3.1). \vr{[0..7]} \note the specification sais it is an enumerated value.
// Parameter: cell srs subframe for internal implementation
uint8_tsrsCellSubframe;
// Parameter: ue srs subframe for internal implementation
uint8_tsrsUeSubframe;
}SOUNDINGRS_UL_CONFIG_DEDICATED;
/// UplinkPowerControlDedicated Information Element from 36.331 RRC spec
typedefstruct{
/// Parameter: \f$P_\text{0\_UE\_PUSCH}(1)\f$, see TS 36.213 (5.1.1.1), unit dB. \vr{[-8..7]}\n This field is applicable for non-persistent scheduling, only.
int8_tp0_UE_PUSCH;
/// Parameter: Ks, see TS 36.213 (5.1.1.1). \vr{[0..1]}\n en0 corresponds to value 0 corresponding to state “disabled”. en1 corresponds to value 1.25 corresponding to “enabled”. \note the specification sais it is an enumerated value. \warning the enumeration values do not correspond to the given values in the specification (en1 should be 1.25).
uint8_tdeltaMCS_Enabled;
/// Parameter: Accumulation-enabled, see TS 36.213 (5.1.1.1). \vr{[0..1]} 1 corresponds to "enabled" whereas 0 corresponds to "disabled".
uint8_taccumulationEnabled;
/// Parameter: \f$P_\text{0\_UE\_PUCCH}(1)\f$, see TS 36.213 (5.1.2.1), unit dB. \vr{[-8..7]}
int8_tp0_UE_PUCCH;
/// Parameter: \f$P_\text{SRS\_OFFSET}\f$, see TS 36.213 (5.1.3.1). \vr{[0..15]}\n For Ks=1.25 (\ref deltaMCS_Enabled), the actual parameter value is pSRS_Offset value - 3. For Ks=0, the actual parameter value is -10.5 + 1.5*pSRS_Offset value.
int8_tpSRS_Offset;
/// Specifies the filtering coefficient for RSRP measurements used to calculate path loss, as specified in TS 36.213 (5.1.1.1).\details The same filtering mechanism applies as for quantityConfig described in 5.5.3.2. \note the specification sais it is an enumerated value.
uint8_tfilterCoefficient;
}UL_POWER_CONTROL_DEDICATED;
#ifndef OCP_FRAMEWORK
/// Enumeration for parameter \f$\alpha\f$ \ref UL_POWER_CONTROL_CONFIG_COMMON::alpha.
typedefenum{
al0=0,
al04=1,
al05=2,
al06=3,
al07=4,
al08=5,
al09=6,
al1=7
}PUSCH_alpha_t;
#endif
/// \note UNUSED
typedefenum{
deltaFm2=0,
deltaF0,
deltaF1,
deltaF2,
deltaF3,
deltaF5
}deltaF_PUCCH_t;
/// UplinkPowerControlCommon Information Element from 36.331 RRC spec \note this structure does not currently make use of \ref deltaFList_PUCCH_t.
typedefstruct{
/// Parameter: \f$P_\text{0\_NOMINAL\_PUSCH}(1)\f$, see TS 36.213 (5.1.1.1), unit dBm. \vr{[-126..24]}\n This field is applicable for non-persistent scheduling, only.
int8_tp0_NominalPUSCH;
/// Parameter: \f$\alpha\f$, see TS 36.213 (5.1.1.1) \warning the enumeration values do not correspond to the given values in the specification (al04 should be 0.4, ...)!
PUSCH_alpha_talpha;
/// Parameter: \f$P_\text{0\_NOMINAL\_PUCCH}\f$ See TS 36.213 (5.1.2.1), unit dBm. \vr{[-127..-96]}
int8_tp0_NominalPUCCH;
/// Parameter: \f$\Delta_\text{PREAMBLE\_Msg3}\f$ see TS 36.213 (5.1.1.1). \vr{[-1..6]}\n Actual value = IE value * 2 [dB].
int8_tdeltaPreambleMsg3;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 1, see TS 36.213 (5.1.2). \vr{[0..2]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format1;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 1a, see TS 36.213 (5.1.2). \vr{[0..2]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format1a;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 1b, see TS 36.213 (5.1.2). \vr{[0..2]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format1b;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 2, see TS 36.213 (5.1.2). \vr{[0..3]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format2;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 2a, see TS 36.213 (5.1.2). \vr{[0..2]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format2a;
/// Parameter: \f$\Delta_\text{F\_PUCCH}(F)\f$ for the PUCCH format 2b, see TS 36.213 (5.1.2). \vr{[0..2]} \warning check value range, why is this a long? \note the specification sais it is an enumerated value.
longdeltaF_PUCCH_Format2b;
}UL_POWER_CONTROL_CONFIG_COMMON;
/// Union for \ref TPC_PDCCH_CONFIG::tpc_Index.
typedefunion{
/// Index of N when DCI format 3 is used. See TS 36.212 (5.3.3.1.6). \vr{[1..15]}
uint8_tindexOfFormat3;
/// Index of M when DCI format 3A is used. See TS 36.212 (5.3.3.1.7). \vr{[1..31]}
uint8_tindexOfFormat3A;
}TPC_INDEX_t;
/// TPC-PDCCH-Config Information Element from 36.331 RRC spec
typedefstruct{
/// RNTI for power control using DCI format 3/3A, see TS 36.212. \vr{[0..65535]}
uint16_trnti;
/// Index of N or M, see TS 36.212 (5.3.3.1.6 and 5.3.3.1.7), where N or M is dependent on the used DCI format (i.e. format 3 or 3a).
TPC_INDEX_ttpc_Index;
}TPC_PDCCH_CONFIG;
/// Enumeration for parameter SR transmission \ref SCHEDULING_REQUEST_CONFIG::dsr_TransMax.
typedefenum{
sr_n4=0,
sr_n8=1,
sr_n16=2,
sr_n32=3,
sr_n64=4
}DSR_TRANSMAX_t;
/// SchedulingRequestConfig Information Element from 36.331 RRC spec
typedefstruct{
/// Parameter: \f$n^{(1)}_\text{PUCCH,SRI}\f$, see TS 36.213 (10.1). \vr{[0..2047]}
uint16_tsr_PUCCH_ResourceIndex;
/// Parameter: \f$I_\text{SR}\f$, see TS 36.213 (10.1). \vr{[0..155]}
uint8_tsr_ConfigIndex;
/// Parameter for SR transmission in TS 36.321 (5.4.4). \details The value n4 corresponds to 4 transmissions, n8 corresponds to 8 transmissions and so on.
/// Parameter: CQI/PMI Periodicity and Offset Configuration Index \f$I_\text{CQI/PMI}\f$, see TS 36.213 (tables 7.2.2-1A and 7.2.2-1C). \vr{[0..1023]}
int16_tcqi_PMI_ConfigIndex;
/// Parameter: K, see 36.213 (4.2.2). \vr{[1..4]}
uint8_tK;
/// Parameter: RI Config Index \f$I_\text{RI}\f$, see TS 36.213 (7.2.2-1B). \vr{[0..1023]}, -1 indicates inactivity
int16_tri_ConfigIndex;
/// Parameter: Simultaneous-AN-and-CQI, see TS 36.213 (10.1). \vr{[0..1]} 1 indicates that simultaneous transmission of ACK/NACK and CQI is allowed.
uint8_tsimultaneousAckNackAndCQI;
/// parameter computed from Tables 7.2.2-1A and 7.2.2-1C
uint16_tNpd;
/// parameter computed from Tables 7.2.2-1A and 7.2.2-1C
uint16_tN_OFFSET_CQI;
}CQI_REPORTPERIODIC;
/// Enumeration for parameter reporting mode \ref CQI_REPORT_CONFIG::cqi_ReportModeAperiodic.
typedefenum{
rm12=0,
rm20=1,
rm22=2,
rm30=3,
rm31=4
}CQI_REPORTMODEAPERIODIC;
/// CQI-ReportConfig Information Element from 36.331 RRC spec
typedefstruct{
/// Parameter: reporting mode. Value rm12 corresponds to Mode 1-2, rm20 corresponds to Mode 2-0, rm22 corresponds to Mode 2-2 etc. PUSCH reporting modes are described in TS 36.213 [23, 7.2.1].
CQI_REPORTMODEAPERIODICcqi_ReportModeAperiodic;
/// Parameter: \f$\Delta_\text{offset}\f$, see TS 36.213 (7.2.3). \vr{[-1..6]}\n Actual value = IE value * 2 [dB].
int8_tnomPDSCH_RS_EPRE_Offset;
CQI_REPORTPERIODICCQI_ReportPeriodic;
}CQI_REPORT_CONFIG;
/// MBSFN-SubframeConfig Information Element from 36.331 RRC spec \note deviates from specification.
typedefstruct{
/// MBSFN subframe occurance. \details Radio-frames that contain MBSFN subframes occur when equation SFN mod radioFrameAllocationPeriod = radioFrameAllocationOffset is satisfied. When fourFrames is used for subframeAllocation, the equation defines the first radio frame referred to in the description below. Values n1 and n2 are not applicable when fourFrames is used. \note the specification sais it is an enumerated value {n1, n2, n4, n8, n16, n32}.
intradioframeAllocationPeriod;
/// MBSFN subframe occurance. \vr{[0..7]}\n Radio-frames that contain MBSFN subframes occur when equation SFN mod radioFrameAllocationPeriod = radioFrameAllocationOffset is satisfied. When fourFrames is used for subframeAllocation, the equation defines the first radio frame referred to in the description below. Values n1 and n2 are not applicable when fourFrames is used.
/// "1" denotes that the corresponding subframe is allocated for MBSFN. The following mapping applies:\n FDD: The first/leftmost bit defines the MBSFN allocation for subframe #1, the second bit for #2, third bit for #3 , fourth bit for #6, fifth bit for #7, sixth bit for #8.\n TDD: The first/leftmost bit defines the allocation for subframe #3, the second bit for #4, third bit for #7, fourth bit for #8, fifth bit for #9. Uplink subframes are not allocated. The last bit is not used.
/// \par fourFrames_flag == 1
/// A bit-map indicating MBSFN subframe allocation in four consecutive radio frames, "1" denotes that the corresponding subframe is allocated for MBSFN. The bitmap is interpreted as follows:\n FDD: Starting from the first radioframe and from the first/leftmost bit in the bitmap, the allocation applies to subframes #1, #2, #3 , #6, #7, and #8 in the sequence of the four radio-frames.\n TDD: Starting from the first radioframe and from the first/leftmost bit in the bitmap, the allocation applies to subframes #3, #4, #7, #8, and #9 in the sequence of the four radio-frames. The last four bits are not used. Uplink subframes are not allocated.
intmbsfn_SubframeConfig;
}MBSFN_config_t;
#if (LTE_RRC_VERSION >= MAKE_VERSION(14, 0, 0))
typedefstruct{
intradioframeAllocationPeriod;
intradioframeAllocationOffset;
intnon_mbsfn_SubframeConfig;
}NonMBSFN_config_t;
#endif
typedefstruct{
/// Number of resource blocks (RB) in DL
uint8_tN_RB_DL;
/// Number of resource blocks (RB) in UL
uint8_tN_RB_UL;
/// EUTRA Band
uint8_teutra_band;
/// DL carrier frequency
uint32_tdl_CarrierFreq;
/// UL carrier frequency
uint32_tul_CarrierFreq;
/// TX attenuation
uint32_tatt_tx;
/// RX attenuation
uint32_tatt_rx;
/// total Number of Resource Block Groups: this is ceil(N_PRB/P)
uint8_tN_RBG;
/// Total Number of Resource Block Groups SubSets: this is P
uint8_tN_RBGS;
/// Cell ID
uint16_tNid_cell;
/// MBSFN Area ID
uint16_tNid_cell_mbsfn;
/// Cyclic Prefix for DL (0=Normal CP, 1=Extended CP)
lte_prefix_type_tNcp;
/// Cyclic Prefix for UL (0=Normal CP, 1=Extended CP)
if(ndlsch_harq->round==0){//first transmission so we encode... because we generate the sequence
if(eNB->mac_enabled==1){// set in lte-softmodem/main line 1646
DLSCH_pdu=pdu;
/*
* we don't need to manage the RAR here since should be managed in the MAC layer for two reasons:
* 1)we should receive directly the pdu containing the RAR from the MAC in the schedule_response
* 2)all the parameters for getting the MSG3 should be given by the UL_CONFIG.request (all inside the next schedule_response function)
*
*/
//fill_rar shouduld be in the MAC
//cancel ra procedure should be in the mac
//scheduling request not implemented in NB-IoT
//nulsch_param configuration for MSG3 should be considered in handling UL_Config.request
//(in particular the nulsch structure for RAR is distinguished based on the harq_process->rar_alloc and the particular subframe in which we should have Msg3)
}
else{//XXX we should change taus function???
DLSCH_pdu=DLSCH_pdu_tmp;
for(i=0;i<input_buffer_length;i++)
DLSCH_pdu[i]=(unsignedchar)(taus()&0xff);
}
}
else{
//We are doing a retransmission (harq round > 0
#ifdef DEBUG_PHY_PROC
#ifdef DEBUG_DLSCH
LOG_D(PHY,"[eNB] This DLSCH is a retransmission\n");
#endif
#endif
}
if(eNB->abstraction_flag==0){// used for simulation of the PHY??
//we can distinguish among the different kind of NDLSCH structure (example)
switch(ndlsch->ndlsch_type)
{
caseSIB1:
break;
caseSI_Message:
break;
caseRAR://maybe not needed
break;
caseUE_Data://maybe not needed
break;
}
/*
* 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
* begin (see params Nf, Ns)
*/
// 36-212
//encoding---------------------------
/*
*
* 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
* begin (see params Nf, Ns)
*
* we should have as an iput parameter also G for the encoding based on the switch/case over eutracontrolRegionSize (if exist) and operationModeInfo if defined
* NB: switch case of G is the same for npdsch and npdcch
*
* npdsch_start symbol index
* -refers to TS 36.213 ch 16.4.1.4:
* -if subframe k is a subframe for receiving the SIB1-NB
* -- if operationModeInfo set to 00 or 01 (in band) --> npdsch_start_sysmbol = 3
* -- otherwise --> npdsch_start_symbol = 0
* -if the k subframe is not for SIB1-NB
* --npdsch_start_symbol = eutracontrolregionsize (defined for in-band operating mode (mode 0,1 for FAPI specs) and take values 1,2,3 [units in number of OFDM symbol])
* - otherwise --> npdsch_start_symbol = 0
* (is the starting OFDM for the NPDSCH transmission in the first slot in a subframe k)
* FAPI style:
* npdsch_start symbol is stored in the ndlsch structure from the reception of the NPDLSCH PDU in the DL_CONFIG.request (so should be set by the MAC and put inside the schedule response)
* Nsf needed as an input (number of subframe)-->inside harq_process of ndlsch
*/
switch(ndlsch->npdsch_start_symbol)
{
case0:
G=304;
break;
case1:
G=240;
break;
case2:
G=224;
break;
case3:
G=200;
break;
default:
LOG_E(PHY,"npdsch_start_index has unwanted value\n");
* The MAC schedule the schedule_response in a SUBFRAME BASE (at least because otherwise we have problem with our assumptions on SI transmission)
*
*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 for SI-Message (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)
*
*
*We assume that whenever the NDLSCH pdu is a BCCH type, we consider as if it's a SIB1 while in other case can be data or SI-message depending on the RNTI
*
* **relevant aspects for the System information Transmission (Table 4-47 NDLSCH FAPi specs)
* 1)RNTI type = 0 (contains a BCCH)
* 2)Repetition number == scheduling info SIB1 mapped into 4-8-16
* 3)RNTI (0xFFFF = SI-RNTI)
* (see schedule_response implementation)
*
*/
/*
* This function is triggered by the schedule_response
* (the frequency at which is transmitted to the PHY depends on the MAC scheduler implementation)
// 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)