Conflicts:
	openair1/SCHED/phy_procedures_lte_ue.c
	targets/RT/USER/lte-softmodem.c
	targets/SIMU/USER/oaisim.c
	targets/SIMU/USER/oaisim_functions.c

This commit follows 7d9945e8.

lte-softmodem UE in S1 and lte-softmodem UE in noS1 modes behave
differently here.

This commit fixes the issue for thoses cases.

Other cases (eNB S1, eNB noS1, oaisim S1/noS1) have to be checked.

- fix OPc key
- clear EHPLMN_LIST, UE does not start the RA procedure when set
  to be fixed

This commit is a continuation of 614d6bbe
(ue_ip: use correct instance).

Now in openair2/NETWORK_DRIVER/UE_IP/common.c the 'inst' is not
forced to 1 anymore, we take the value 'pdcph_p->inst'.

It turns out that 'pdcph_p->inst' is 0 instead of 1 when we
run lte-softmodem as an UE.

So let's modify PDCP to set 'inst' to 1 where it was set to 0 for
the UE softmodem case, and skip the places where it is reset to 0,
still for the UE softmodem case.

This may break things, I am not sure.

Guess what happens when we return from the function...

For whatever reason, lte-softmodem.c was totally messed up...

We took the version from the branch develop and added
abstraction_flag, which is needed in openair2/LAYER2/MAC/main.c
(this is not clean, previous commit added a comment for this).
This has to be cleaned at some point.

- the option --UE was abused! Let's introduce --UE-conf-nvram and
  --UE-gen-nvram
- the option name --UE-OUTPUT was not clear and is now replaced by
  --UE-gen-nvram
- the new options are described when running ./build_oai -h
- print_help has been modified (' replaced by ") to print
  $conf_nvram_path and $gen_nvram_path

Conflicts:
	openair1/PHY/LTE_TRANSPORT/dlsch_demodulation.c
	openair1/PHY/LTE_TRANSPORT/power_control.c
	openair2/LAYER2/MAC/eNB_scheduler_dlsch.c
	targets/SIMU/USER/oaisim_functions.c

The problem was the following.

Run oaisim with two UEs:

    sudo ../cmake_targets/oaisim_build_oai/build/oaisim -O enb.conf -u2 -s15 -AAWGN -y1 -b1 -Q0

Then wait for both UEs to be connected. The interfaces "oip1" and "oip2" are
activated, with IP addresses 192.172.0.2 for the first UE and 192.172.0.3 for
the second.

Then on the EPC machine, do:

    ping 192.172.0.3

No reply.
On the oaisim machine, we see that the packets are sent to "oip1" instead
of "oip2".

The fix may break softmodem UE. The inst was forced to "1" for some reason.
To be checked.

The memset was also too big. It should only clear
one subframe.

Only tested without abstraction.
Abstraction does not work for the moment anyway, but just to
keep that in mind.

The idea is as follows.

oaisim waits for all tasks to be done for a TTI.
To do so it waits for last_rx_timestamp == current_rx_timestamp,
for all UEs and eNBs.

When it's done, it increases current_rx_timestamp by samples_per_tti,
to inform UEs and eNBs that a new TTI is ready.

In the functions [UE|eNB]_trx_read, we wait for a new TTI to be ready,
that is we wait for current_rx_timestamp != last_rx_timestamp.

The UE has also to wait for processing threads to be done.
In the eNB it's not necessary because the processing is all
done in one thread, that is: read subframe, process this subframe,
emit subframe+4, and then back to read subframe.

The code is not clean. We should not use usleep but semaphores.

Also, do_[DL|UL]_sig should not read from rxdata and write to txdata,
but use internal buffers.

The functions [UE|eNB]_trx_read should call do_[DL|UL]_sig and then
copy from the internal buffers of the channel simulator into rxdata.

The functions [UE|eNB]_trx_write should write data passed into the
internal buffers of the channel simulator.

This is done in another function.

Don't do it twice.
The logic is: if ndi changed or it's a first tx then round=0
and later: if round==0 then status=ACTIVE

Note: the dci formats 2, 2A and 1E were not checked,
this has to be done. dlsch[0] and dlsch[1] (when
applicable) must be checked somehow.

Develop integration w06

See merge request !110

Not sure at all about this one, seemed necessary to me,
but I don't get the full logic in there.

To be refined.

This is done a bit above in the code, no need to do it twice.

I am not sure this is enough. To be refined.

I doubt the case should happen. If it does, let's print an
error, will ease debugging.

Not sure if necessary, but better do it.

This reverts commit ce14050b, reversing
changes made to 0ada1e9e.

 Conflicts:
	openair1/PHY/LTE_TRANSPORT/prach.c
	targets/ARCH/ETHERNET/USERSPACE/LIB/ethernet_lib.c

 Conflicts:
	openair2/LAYER2/MAC/flexran_agent_scheduler_dlsch_ue.c

 Conflicts:
	openair1/PHY/MODULATION/ofdm_mod.c

 Conflicts:
	openair2/RRC/LITE/rrc_UE.c