How to get LTE Cell Id within multi-model-spectrum-channel.cc?

[Shyam Parekh]

I'm trying to get access to the cell Id associated with a transmission being processed in multi-model-spectrum-channel.cc. This is for adjusting the path loss in a customized fashion based on the cell Id.

The logic I'm trying to implement is to first get access to "Ptr<LteEnbNetDevice> enbDev" associated with the transmission, and then get the cell Id through "enbDev->GetCellId ()".

For obtaining enbDev, I'm using the following:

Ptr<LteEnbNetDevice> enbDev = txParams->txPhy->GetDevice ()->GetObject <LteEnbNetDevice> ()

I believe this worked prior to 3.38, but now I'm getting errors. Has something changed? Please let me know if you have any suggestions.

Thanks,

Shyam

[Shyam Parekh]

I forgot to mention that there are only downlink transmissions present in my scenario.

Shyam

[Shyam Parekh]

Sorry for sending multiple messages for this issue. But, just to complete the picture, I do have "#include <ns3/lte-enb-net-device.h>", and "Ptr<NetDevice> txNetDevice = txParams->txPhy->GetDevice()" works. I'm having trouble obtaining LteEnbNetDevice from NetDevice.

Shyam

[Tommaso Pecorella]

Let me understand, you're trying to get the EnbNetDevice pointer from the UeNetDevice ?

If this is the case, then yes, you'll face issues, simply because a UE shouldn't even try to access the EnbNetDevice pointer.

On the other hand, a UE should be able to report the CellId it is attached to without having to resort to tricks, and (of course) a eNB should be able to tell what is its own cellId.

My suggestion is to verify in the UE where is that info.

[Shyam Parekh]

Thanks Tommaso!

 

I'm actually trying to get the EnbNetDevice pointer from the NetDevice pointer.  I've a scenario where only DL UDP transmissions are happening. So, all the transmissions handled in multi-model-spectrum-channel.cc are coming from an eNB. Previously, in 3.36, I was able to use the following to get the cellId within multi-model-spectrum-channel.cc.

Ptr<LteEnbNetDevice> enbDev = txParams->txPhy->GetDevice ()->GetObject <LteEnbNetDevice> ();

int cellId = enbDev->GetCellId ();

Now, with 3.38, I get errors. In 3.38, "Ptr<NetDevice> txNetDevice = txParams->txPhy->GetDevice()" does work. So, I'm trying to figure out how to get the EnbNetDevice pointer from the NetDevice pointer.

Thanks,

Shyam

[Tommaso Pecorella]

I assume you're trying to modify LteSpectrumPhy.

Mind that both UEs and eNBs does have one of these objects, so your code have to have some "if" statements.

Inside that class you have a pointer to "m_device", which SHOULD be the thing you're looking for.

What you have to do is a DynamicCast, like:

Ptr<LteEnbNetDevice> enbPtr = DynamicCast<LteEnbNetDevice>(m_device);

if (enbPtr)

{

....

}

However, please to be a BIT more precise in your questions.

[Shyam Parekh]

Thanks Tommaso! Your suggestion makes good sense. However, when I try this, I keep on getting the following error:

.../ns-3.38/build/lib/libns3.38-spectrum-default.so: undefined symbol: _ZTIN3ns315LteEnbNetDeviceE

I've been trying to resolve this for the past two days, but can't figure it out. I've tried a number variations, but the attached file (from .../ns-3.38/src/spectrum/model) contains the simplest one. Here, to the original multi-model-spectrum-channel.cc, I first add the following in lines 18-19

//Added
#include <ns3/lte-enb-net-device.h>

and the following in lines 351-353

//Added
                        Ptr<NetDevice> txNetDevice = txParams->txPhy->GetDevice();
                        Ptr<LteEnbNetDevice> enbDev = DynamicCast<LteEnbNetDevice>(txNetDevice);

If I comment out the last line, there is no error. txNetDevice seems to be getting correctly identified, and its TypeId does show as ns3::NetDevice. Just FYI, I also tried to first access LteNetDevice - the first derived class from NetDevice, but it didn't work. I'm really puzzled here. What am I doing wrong?

Thanks,

Shyam

[Tommaso Pecorella]

Sorry to be the bearer of bad news, but you can't do that (and you shouldn't).

This is called a circular dependency between modules. Module A (LTE) needs Module B (Spectrum), and with your attempt Module B (Spectrum) needs Module A (LTE). Even though this could be (theoretically) done, we specifically forbid in ns-3 because it causes an incredible number of problems.

You can modify whatever you need in the LTE module, but you can not put some code referring to the LTE module inside the spectrum module, because LTE depends on spectrum.

Sorry.

[Shyam Parekh]

Thanks Tommaso!

I'm now confused. All I want is just to identify the LteEnbNetDevice associated with the current transmission in LteSpectrumPhy. I'm not modifying LteEnbNetDevice. A similar thing is done elsewhere in LteSpectrumPhy. For example, line 301 of the file I attached has the following:

Ptr<NetDevice> txNetDevice = txParams->txPhy->GetDevice();

Just as this line in the original code is identifying the NetDevice associated with the transmission, I would like to identify LteEnbNetDevice associated with the transmission.

Please let me know your thoughts. Thanks again for your help!

Shyam

[Tommaso Pecorella]

In your previous post you said you are trying to modify multi-model-spectrum-channel.cc, which is part of the spectrum module. My answer do apply to that file and module. 

[Shyam Parekh]

I'm trying to change pathLossDb by a value that depends on the transmit (i.e., source) cell associated with the current transmission. Interestingly, I can get the transmit nodeId associated with the current transmission in multi-model-spectrum-channel.cc. Since I know the cellId associated with each Enb node, I can "manually" get the cellId from the nodeId. It seems strange to me that I can identify the transmit node and the transmit device associated with the current transmission in multi-model-spectrum-channel.cc, but not the transmit Enb.

Thanks,

Shyam

[Tommaso Pecorella]

Each module has dependencies, and they're listed in the CMakeLists.txt file in each module in the section "LIBRARIES_TO_LINK".

If you graph the dependencies, and the dependencies of the dependencies, and so forth, you'll get a directed graph. You can refer to anything that is "up" because it will be linked. You can't refer to stuff that is "down" because it will not be linked.

Nodes and NetDevices are defined in the network model, which is close to the top of the graph - practically any model can use stuff defined in the network model. LTE... no.

[Tommaso Pecorella]

BTW, the pathLoss can not (physically) be dependent on the CellId, simply because it is a PATH loss - it's dependent on the environment, i.e., where the eNB and UEs are positioned, and what is in between them.

My best suggestion is to think twice about what you're trying to do, why you're trying to do it, and what is the physical scenario you're trying to implement. When you'll have a clear picture you'll find a way to do things.

As a simple example, the Building model can assign different path losses to different eNB, but not because they have different path losses based on the CellId - because the eNBs are inside or outside a BUILDING. It's a position, not a cell identification.

[Shyam Parekh]

Thanks Tommaso for the last two helpful messages.

This pathLossDb adjustment has to do with antenna tilting (and hence the cellId dependency). Since LTE does not model antenna tilting, we found that one way to account for it is by adjusting propagationGainDb (and hence pathLossDb).

Thanks,

Shyam

[Tommaso Pecorella]

What about this:

src/antenna/model/uniform-planar-array.cc:79:            .AddAttribute("DowntiltAngle",

[Tommaso Pecorella]

Moreover, it could be maybe easier, and for sure more useful to you and the community to add the tilt param to the antennas.

[Shyam Parekh]

Hi Tommasso,

We're focusing on a single antenna models currently, but should start looking phased array antennas soon. I would love to see an example of how Uniform Planar Array antennas are used with LTE. There seems to be a difference in how one can use this (selecting an antenna type vs. configuring an object - not sure).

It seems the NR (5G-LENA) has better handle on antenna tilting (as illustrated in NR's lena-lte-comparison example). So, it's probably not worthwhile to spend much time on adding/improving support for antenna tilting in LTE.

Thanks,

Shyam