LteHelper::InstallSingleEnbDevice's use of ObjectFactory for some objects but not all

[Peter Danielsen]

Hi,

I'm looking at the code for LteHelper::InstallSingleEnbDevice and see that some objects are created with hard-coded types, such as
  Ptr<LteEnbMac> mac = CreateObject<LteEnbMac> ();
 while others use an ObjectFactory, such as
  Ptr<FfMacScheduler> sched = m_schedulerFactory.Create<FfMacScheduler> ();

What's the philosophy for using the former method for creating the layers (PHY, MAC, RRC) instead of an ObjectFactory, which would allow experimentation with alternate implementations?  I have the same question for UeManager's creation of the PDCP and RLC layers.

Thanks,

Peter

[Tommaso Pecorella]

Hi,

I can only guess that it's an implementation choice. Perhaps the coder didn't foresee the need to use a factory, or he/she decided that the change could be done in the future.

After all, to use a different layer implementation, usually you need much more than "just" a factory, you need also an abstraction layer.

Cheers,

T.

[Peter Danielsen]

Thanks for the reply.

Is there a recommended way to experiment with different layer implementations?   Two that come to mind are

1. Create a new class to use instead of LteHelper.  It would probably mostly be the same as LteHelper, but instantiating the alternative layer implementations.
2. Do not use LteHelper and effectively inline its code instead, but with the alternative layer implementations.

Both alternatives unfortunately involve code duplication.

I would have thought that the factory approach in LteHelper would suffice due to standardized layer APIs (as is done for scheduler selection)?

Peter

[Tommaso Pecorella]

Hi,

you forgot option 3:

- modify LteHelper to fit your needs.

T.