F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

merge

Browse Source
This commit is contained in:
Marco Miozzo
2013-01-18 12:10:00 +01:00
parent 94d537dda4 06dee432a9
commit e5b2e517e4
12 changed files with 22 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
src/lte/doc/source/figures/lte-arch-enb-data.dia
View File

Binary file not shown.

22
src/lte/doc/source/figures/lte-enb-rrc-states.dot
View File

@@ -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"]

BIN
src/lte/doc/source/figures/lte-ue-phy.dia
View File

Binary file not shown.

8
src/lte/doc/source/lte-design.rst
View File

@@ -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].

8
src/lte/helper/radio-bearer-stats-calculator.cc
View File

@@ -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)
{

4
src/lte/model/epc-enb-application.cc
View File

@@ -289,7 +289,7 @@ EpcEnbApplication::RecvFromS1uSocket (Ptr<Socket> socket)
void
EpcEnbApplication::SendToLteSocket (Ptr<Packet> 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> packet, uint16_t rnti, uint8_t b
void
EpcEnbApplication::SendToS1uSocket (Ptr<Packet> 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

26
src/lte/model/lte-rrc-protocol-ideal.cc
View File

@@ -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

1
src/lte/model/lte-rrc-protocol-ideal.h
View File

@@ -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);

25
src/lte/model/lte-rrc-protocol-real.cc
View File

@@ -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)
{

1
src/lte/model/lte-rrc-protocol-real.h
View File

@@ -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);

9
src/lte/model/lte-rrc-sap.h
View File

@@ -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<C>::Setup (SetupParameters params)
m_owner->DoSetup (params);
}
template <class C>
void
MemberLteUeRrcSapUser<C>::Reestablish ()
{
m_owner->DoReestablish ();
}
template <class C>
void
MemberLteUeRrcSapUser<C>::SendRrcConnectionRequest (RrcConnectionRequest msg)

1
src/lte/model/lte-ue-rrc.cc
View File

@@ -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);
}