diff --git a/src/lte/doc/source/figures/lte-arch-enb-data.dia b/src/lte/doc/source/figures/lte-arch-enb-data.dia index 16a902056..82dccadcc 100644 Binary files a/src/lte/doc/source/figures/lte-arch-enb-data.dia and b/src/lte/doc/source/figures/lte-arch-enb-data.dia differ diff --git a/src/lte/doc/source/figures/lte-enb-rrc-states.dot b/src/lte/doc/source/figures/lte-enb-rrc-states.dot index 1e9b028be..cd3063105 100644 --- a/src/lte/doc/source/figures/lte-enb-rrc-states.dot +++ b/src/lte/doc/source/figures/lte-enb-rrc-states.dot @@ -4,21 +4,21 @@ size="20,20" NO_CONTEXT [shape="ellipse", label="no context"] -INITIAL_RANDOM_ACCESS [shape="box",width=5] -CONNECTION_SETUP [shape="box",width=5] -CONNECTION_REJECTED [shape="box",width=5] -CONNECTED_NORMALLY [shape="box",width=5] -CONNECTION_RECONFIGURATION [shape="box",width=5] -HANDOVER_PREPARATION [shape="box",width=5] -HANDOVER_JOINING [shape="box",width=5] -HANDOVER_PATH_SWITCH [shape="box",width=5] -HANDOVER_LEAVING [shape="box",width=5] +INITIAL_RANDOM_ACCESS [shape="box",width=4] +CONNECTION_SETUP [shape="box",width=4] +CONNECTION_REJECTED [shape="box",width=4] +CONNECTED_NORMALLY [shape="box",width=4] +CONNECTION_RECONFIGURATION [shape="box",width=4] +HANDOVER_PREPARATION [shape="box",width=4] +HANDOVER_JOINING [shape="box",width=4] +HANDOVER_PATH_SWITCH [shape="box",width=4] +HANDOVER_LEAVING [shape="box",width=4] CONTEXT_DESTROYED [shape="ellipse", label="context destroyed"] NO_CONTEXT -> INITIAL_RANDOM_ACCESS [label="rx RA preamble",labeldistance=0] INITIAL_RANDOM_ACCESS -> CONNECTION_REJECTED [label="rx RRC CONN REQUEST, AdmitRrcConnectionRequest = false"] -CONNECTION_REJECTED -> CONTEXT_DESTROYED [label="maxConnectionDelay timeout"] -INITIAL_RANDOM_ACCESS -> CONTEXT_DESTROYED [label="maxRecvConnRejectDelay timeout"] +CONNECTION_REJECTED -> CONTEXT_DESTROYED [label="maxRecvConnRejectDelay timeout"] +INITIAL_RANDOM_ACCESS -> CONTEXT_DESTROYED [label="maxConnectionDelay timeout"] INITIAL_RANDOM_ACCESS -> CONNECTION_SETUP [label="rx RRC CONN REQUEST, AdmitRrcConnectionRequest = true"] CONNECTION_SETUP -> CONNECTED_NORMALLY [label="rx RRC CONN SETUP COMPLETED"] CONNECTED_NORMALLY -> CONNECTION_RECONFIGURATION [label="reconfiguration trigger"] diff --git a/src/lte/doc/source/figures/lte-ue-phy.dia b/src/lte/doc/source/figures/lte-ue-phy.dia index 61d8013b8..fdb76a1f2 100644 Binary files a/src/lte/doc/source/figures/lte-ue-phy.dia and b/src/lte/doc/source/figures/lte-ue-phy.dia differ diff --git a/src/lte/doc/source/lte-design.rst b/src/lte/doc/source/lte-design.rst index ccb27023c..032c2cea8 100644 --- a/src/lte/doc/source/lte-design.rst +++ b/src/lte/doc/source/lte-design.rst @@ -703,17 +703,17 @@ The simulator includes the error model for downlink control channels (PCFICH and PCFICH + PDCCH Error Model -------------------------- -The model adopted for the error distribution of these channels is based on an evaluation study carried out in the RAN4 of 3GPP, where different vendors investigated the demodulation performance of the PCFICH jointly with PDCCH. This is due to the fact that the PCFICH is the channel in charge of communicating to the UEs the actual dimension of the PDCCH (which spans between 1 and 3 symbols); therefore the correct decodification of the DCIs depends on the correct interpretation of both ones. In 3GPP this problem have been evaluated for improving the cell-edge performance _[FujitsuWhitePaper], where the interference among neighboring cells can be relatively high due to signal degradation. A similar problem has been notices in femto-cell scenario and, more in general, in HetNet scenarios the bottleneck has been detected mainly as the PCFICH channel _[Bharucha2011], where in case of many eNBs are deployed in the same service area, this channel may collide in frequency, making impossible the correct detection of the PDCCH channel, too. +The model adopted for the error distribution of these channels is based on an evaluation study carried out in the RAN4 of 3GPP, where different vendors investigated the demodulation performance of the PCFICH jointly with PDCCH. This is due to the fact that the PCFICH is the channel in charge of communicating to the UEs the actual dimension of the PDCCH (which spans between 1 and 3 symbols); therefore the correct decodification of the DCIs depends on the correct interpretation of both ones. In 3GPP this problem have been evaluated for improving the cell-edge performance [FujitsuWhitePaper]_, where the interference among neighboring cells can be relatively high due to signal degradation. A similar problem has been notices in femto-cell scenario and, more in general, in HetNet scenarios the bottleneck has been detected mainly as the PCFICH channel [Bharucha2011]_, where in case of many eNBs are deployed in the same service area, this channel may collide in frequency, making impossible the correct detection of the PDCCH channel, too. -In the simulator, the SINR perceived during the reception has been estimated according to the MIESM model presented above in order to evaluate the error distribution of PCFICH and PDCCH. In detail, the SINR samples of all the RBs are included in the evaluation of the MI associated to the control frame and, according to this values, the effective SINR (eSINR) is obtained by inverting the MI evaluation process. It has to be noted that, in case of MIMO transmission, both PCFICH and the PDCCH use always the transmit diversity mode as defined by the standard. According to the eSINR perceived the decodification error probability can be estimated as function of the results presented in _[R4-081920]. In case an error occur, the DCIs discarded and therefore the UE will be not able to receive the correspondent Tbs, therefore resulting lost. +In the simulator, the SINR perceived during the reception has been estimated according to the MIESM model presented above in order to evaluate the error distribution of PCFICH and PDCCH. In detail, the SINR samples of all the RBs are included in the evaluation of the MI associated to the control frame and, according to this values, the effective SINR (eSINR) is obtained by inverting the MI evaluation process. It has to be noted that, in case of MIMO transmission, both PCFICH and the PDCCH use always the transmit diversity mode as defined by the standard. According to the eSINR perceived the decodification error probability can be estimated as function of the results presented in [R4-081920]_. In case an error occur, the DCIs discarded and therefore the UE will be not able to receive the correspondent Tbs, therefore resulting lost. MIMO Model ++++++++++ -The use of multiple antennas both at transmitter and receiver side, known as multiple-input and multiple-output (MIMO), is a problem well studied in literature during the past years. Most of the work concentrate on evaluating analytically the gain that the different MIMO schemes might have in term of capacity; however someones provide also information of the gain in terms of received power _[CatreuxMIMO]. +The use of multiple antennas both at transmitter and receiver side, known as multiple-input and multiple-output (MIMO), is a problem well studied in literature during the past years. Most of the work concentrate on evaluating analytically the gain that the different MIMO schemes might have in term of capacity; however someones provide also information of the gain in terms of received power [CatreuxMIMO]_. -According to the considerations above, a model more flexible can be obtained considering the gain that MIMO schemes bring in the system from a statistical point of view. As highlighted before, _[CatreuxMIMO] presents the statistical gain of several MIMO solutions respect to the SISO one in case of no correlation between the antennas. In the work the gain is presented as the cumulative distribution function (CDF) of the output SINR for what concern SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE and MIMO-ZF schemes. Elaborating the results, the output SINR distribution can be approximated with a log-normal one with different mean and variance as function of the scheme considered. However, the variances are not so different and they are approximatively equal to the one of the SISO mode already included in the shadowing component of the ``BuildingsPropagationLossModel``, in detail: +According to the considerations above, a model more flexible can be obtained considering the gain that MIMO schemes bring in the system from a statistical point of view. As highlighted before, [CatreuxMIMO]_ presents the statistical gain of several MIMO solutions respect to the SISO one in case of no correlation between the antennas. In the work the gain is presented as the cumulative distribution function (CDF) of the output SINR for what concern SISO, MIMO-Alamouti, MIMO-MMSE, MIMO-OSIC-MMSE and MIMO-ZF schemes. Elaborating the results, the output SINR distribution can be approximated with a log-normal one with different mean and variance as function of the scheme considered. However, the variances are not so different and they are approximatively equal to the one of the SISO mode already included in the shadowing component of the ``BuildingsPropagationLossModel``, in detail: * SISO: :math:`\mu = 13.5` and :math:`\sigma = 20` [dB]. * MIMO-Alamouti: :math:`\mu = 17.7` and :math:`\sigma = 11.1` [dB]. diff --git a/src/lte/helper/radio-bearer-stats-calculator.cc b/src/lte/helper/radio-bearer-stats-calculator.cc index 323ee96a5..79b09dbb8 100644 --- a/src/lte/helper/radio-bearer-stats-calculator.cc +++ b/src/lte/helper/radio-bearer-stats-calculator.cc @@ -133,7 +133,7 @@ RadioBearerStatsCalculator::GetEpoch () const void RadioBearerStatsCalculator::UlTxPdu (uint16_t cellId, uint64_t imsi, uint16_t rnti, uint8_t lcid, uint32_t packetSize) { - NS_LOG_FUNCTION (this << "UlTxPDU" << imsi << rnti << (uint32_t) lcid << packetSize); + NS_LOG_FUNCTION (this << "UlTxPDU" << cellId << imsi << rnti << (uint32_t) lcid << packetSize); ImsiLcidPair_t p (imsi, lcid); if (Simulator::Now () > m_startTime) { @@ -148,7 +148,7 @@ RadioBearerStatsCalculator::UlTxPdu (uint16_t cellId, uint64_t imsi, uint16_t rn void RadioBearerStatsCalculator::DlTxPdu (uint16_t cellId, uint64_t imsi, uint16_t rnti, uint8_t lcid, uint32_t packetSize) { - NS_LOG_FUNCTION (this << "DlTxPDU" << imsi << rnti << (uint32_t) lcid << packetSize); + NS_LOG_FUNCTION (this << "DlTxPDU" << cellId << imsi << rnti << (uint32_t) lcid << packetSize); ImsiLcidPair_t p (imsi, lcid); if (Simulator::Now () > m_startTime) { @@ -164,7 +164,7 @@ void RadioBearerStatsCalculator::UlRxPdu (uint16_t cellId, uint64_t imsi, uint16_t rnti, uint8_t lcid, uint32_t packetSize, uint64_t delay) { - NS_LOG_FUNCTION (this << "UlRxPDU" << imsi << rnti << (uint32_t) lcid << packetSize << delay); + NS_LOG_FUNCTION (this << "UlRxPDU" << cellId << imsi << rnti << (uint32_t) lcid << packetSize << delay); ImsiLcidPair_t p (imsi, lcid); if (Simulator::Now () > m_startTime) { @@ -188,7 +188,7 @@ RadioBearerStatsCalculator::UlRxPdu (uint16_t cellId, uint64_t imsi, uint16_t rn void RadioBearerStatsCalculator::DlRxPdu (uint16_t cellId, uint64_t imsi, uint16_t rnti, uint8_t lcid, uint32_t packetSize, uint64_t delay) { - NS_LOG_FUNCTION (this << "DlRxPDU" << imsi << rnti << (uint32_t) lcid << packetSize << delay); + NS_LOG_FUNCTION (this << "DlRxPDU" << cellId << imsi << rnti << (uint32_t) lcid << packetSize << delay); ImsiLcidPair_t p (imsi, lcid); if (Simulator::Now () > m_startTime) { diff --git a/src/lte/model/epc-enb-application.cc b/src/lte/model/epc-enb-application.cc index 59aa4e44a..a5cf7ab36 100644 --- a/src/lte/model/epc-enb-application.cc +++ b/src/lte/model/epc-enb-application.cc @@ -289,7 +289,7 @@ EpcEnbApplication::RecvFromS1uSocket (Ptr socket) void EpcEnbApplication::SendToLteSocket (Ptr packet, uint16_t rnti, uint8_t bid) { - NS_LOG_FUNCTION (this << packet << rnti << (uint16_t) bid); + NS_LOG_FUNCTION (this << packet << rnti << (uint16_t) bid << packet->GetSize ()); EpsBearerTag tag (rnti, bid); packet->AddPacketTag (tag); int sentBytes = m_lteSocket->Send (packet); @@ -300,7 +300,7 @@ EpcEnbApplication::SendToLteSocket (Ptr packet, uint16_t rnti, uint8_t b void EpcEnbApplication::SendToS1uSocket (Ptr packet, uint32_t teid) { - NS_LOG_FUNCTION (this << packet << teid); + NS_LOG_FUNCTION (this << packet << teid << packet->GetSize ()); GtpuHeader gtpu; gtpu.SetTeid (teid); // From 3GPP TS 29.281 v10.0.0 Section 5.1 diff --git a/src/lte/model/lte-rrc-protocol-ideal.cc b/src/lte/model/lte-rrc-protocol-ideal.cc index a400b314a..c9ab7e156 100644 --- a/src/lte/model/lte-rrc-protocol-ideal.cc +++ b/src/lte/model/lte-rrc-protocol-ideal.cc @@ -92,31 +92,7 @@ void LteUeRrcProtocolIdeal::DoSetup (LteUeRrcSapUser::SetupParameters params) { NS_LOG_FUNCTION (this); - // Trick: we use this as a trigger to initialize the RNTI and cellID, - // and to make sure we are talking to the appropriate eNB (e.g., - // after handover). We don't care about SRB0/SRB1 since we use ideal - // RRC messages. - DoReestablish (); -} - -void -LteUeRrcProtocolIdeal::DoReestablish () -{ - NS_LOG_FUNCTION (this); - // // initialize the RNTI and get the EnbLteRrcSapProvider for the - // // eNB we are currently attached to - // m_rnti = m_rrc->GetRnti (); - // SetEnbRrcSapProvider (); - - - // if (m_havePendingRrcConnectionRequest == true) - // { - // Simulator::Schedule (RRC_IDEAL_MSG_DELAY, - // &LteEnbRrcSapProvider::RecvRrcConnectionRequest, - // m_enbRrcSapProvider, - // m_rnti, - // m_pendingRrcConnectionRequest); - // } + // We don't care about SRB0/SRB1 since we use ideal RRC messages. } void diff --git a/src/lte/model/lte-rrc-protocol-ideal.h b/src/lte/model/lte-rrc-protocol-ideal.h index ad91b25f1..5e1ff52af 100644 --- a/src/lte/model/lte-rrc-protocol-ideal.h +++ b/src/lte/model/lte-rrc-protocol-ideal.h @@ -66,7 +66,6 @@ private: // methods forwarded from LteUeRrcSapUser void DoSetup (LteUeRrcSapUser::SetupParameters params); - void DoReestablish (); void DoSendRrcConnectionRequest (LteRrcSap::RrcConnectionRequest msg); void DoSendRrcConnectionSetupCompleted (LteRrcSap::RrcConnectionSetupCompleted msg); void DoSendRrcConnectionReconfigurationCompleted (LteRrcSap::RrcConnectionReconfigurationCompleted msg); diff --git a/src/lte/model/lte-rrc-protocol-real.cc b/src/lte/model/lte-rrc-protocol-real.cc index 9b69f1e22..d10c86e21 100644 --- a/src/lte/model/lte-rrc-protocol-real.cc +++ b/src/lte/model/lte-rrc-protocol-real.cc @@ -95,11 +95,6 @@ void LteUeRrcProtocolReal::DoSetup (LteUeRrcSapUser::SetupParameters params) { NS_LOG_FUNCTION (this); - // Trick: we use this as a trigger to initialize the RNTI and cellID, - // and to make sure we are talking to the appropriate eNB (e.g., - // after handover). We don't care about SRB0/SRB1 since we use real - // RRC messages. - DoReestablish (); m_setupParameters.srb0SapProvider = params.srb0SapProvider; m_setupParameters.srb1SapProvider = params.srb1SapProvider; @@ -113,26 +108,6 @@ LteUeRrcProtocolReal::DoSetup (LteUeRrcSapUser::SetupParameters params) m_ueRrcSapProvider->CompleteSetup (m_completeSetupParameters); } -void -LteUeRrcProtocolReal::DoReestablish () -{ - NS_LOG_FUNCTION (this); - // // initialize the RNTI and get the EnbLteRrcSapProvider for the - // // eNB we are currently attached to - // m_rnti = m_rrc->GetRnti (); - // SetEnbRrcSapProvider (); - - - // if (m_havePendingRrcConnectionRequest == true) - // { - // Simulator::Schedule (RRC_REAL_MSG_DELAY, - // &LteEnbRrcSapProvider::RecvRrcConnectionRequest, - // m_enbRrcSapProvider, - // m_rnti, - // m_pendingRrcConnectionRequest); - // } -} - void LteUeRrcProtocolReal::DoSendRrcConnectionRequest (LteRrcSap::RrcConnectionRequest msg) { diff --git a/src/lte/model/lte-rrc-protocol-real.h b/src/lte/model/lte-rrc-protocol-real.h index 37f617efd..2cb74b678 100644 --- a/src/lte/model/lte-rrc-protocol-real.h +++ b/src/lte/model/lte-rrc-protocol-real.h @@ -70,7 +70,6 @@ public: private: // methods forwarded from LteUeRrcSapUser void DoSetup (LteUeRrcSapUser::SetupParameters params); - void DoReestablish (); void DoSendRrcConnectionRequest (LteRrcSap::RrcConnectionRequest msg); void DoSendRrcConnectionSetupCompleted (LteRrcSap::RrcConnectionSetupCompleted msg); void DoSendRrcConnectionReconfigurationCompleted (LteRrcSap::RrcConnectionReconfigurationCompleted msg); diff --git a/src/lte/model/lte-rrc-sap.h b/src/lte/model/lte-rrc-sap.h index 031231e12..6bc0e1553 100644 --- a/src/lte/model/lte-rrc-sap.h +++ b/src/lte/model/lte-rrc-sap.h @@ -507,7 +507,6 @@ public: }; virtual void Setup (SetupParameters params) = 0; - virtual void Reestablish () = 0; virtual void SendRrcConnectionRequest (RrcConnectionRequest msg) = 0; virtual void SendRrcConnectionSetupCompleted (RrcConnectionSetupCompleted msg) = 0; virtual void SendRrcConnectionReconfigurationCompleted (RrcConnectionReconfigurationCompleted msg) = 0; @@ -631,7 +630,6 @@ public: // inherited from LteUeRrcSapUser virtual void Setup (SetupParameters params); - virtual void Reestablish (); virtual void SendRrcConnectionRequest (RrcConnectionRequest msg); virtual void SendRrcConnectionSetupCompleted (RrcConnectionSetupCompleted msg); virtual void SendRrcConnectionReconfigurationCompleted (RrcConnectionReconfigurationCompleted msg); @@ -661,13 +659,6 @@ MemberLteUeRrcSapUser::Setup (SetupParameters params) m_owner->DoSetup (params); } -template -void -MemberLteUeRrcSapUser::Reestablish () -{ - m_owner->DoReestablish (); -} - template void MemberLteUeRrcSapUser::SendRrcConnectionRequest (RrcConnectionRequest msg) diff --git a/src/lte/model/lte-ue-rrc.cc b/src/lte/model/lte-ue-rrc.cc index 5725fdf3d..4158aace8 100644 --- a/src/lte/model/lte-ue-rrc.cc +++ b/src/lte/model/lte-ue-rrc.cc @@ -436,7 +436,6 @@ LteUeRrc::DoSetTemporaryCellRnti (uint16_t rnti) NS_LOG_FUNCTION (this << rnti); m_rnti = rnti; m_srb0->m_rlc->SetRnti (m_rnti); - m_rrcSapUser->Reestablish (); m_cphySapProvider->SetRnti (m_rnti); }