Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

         recover the full MAGMA-MME log
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

fix(doc): updated the Tutorial with only MAGMA-MME references and logs
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

fix(ci): display state of container when failure, better tshark filtering, auto-undeploy if deploy went wrong
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

integration_2022_wk07_c

See merge request oai/openairinterface5g!1451

This merges the following MRs:
- MR !1436 fairRR LTE scheduler fixes: should make the connection more stable, less UL retransmissions
- MR !1386 phy sync improvements: the 5G NR UE should sync better
- MR !1361 FDD support (no traffic): adds FDD support for the scheduler, but heavy traffic has not been tested
- MR !1447 using uid for PUCCH RRC conf: use the RRC UID to decide on PUCCH resources, should in particular avoid the "PUCCH straddles DC carrier" assert
- fix for 5G F1 RFsim test fail

We compute the preferred DL TDAs when receiving the cellGroup from the
RRC. However, in F1 and the RFsim, it seems that the scheduler tries to
access the preferred DL TDAs before they have been set after receiving
the cellGroup. In this commit, add a simple check to verify the
preferred TDA has been set up.

integration_2022_wk07_b

See merge request oai/openairinterface5g!1448

# Conflicts:
#	openair1/SCHED_NR_UE/phy_procedures_nr_ue.c
#	targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.2x2.usrpn300.conf

integration_2022_wk06_a

See merge request oai/openairinterface5g!1438

Somehow this file was in a bad state...

# Conflicts:
#	targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band41.fr1.106PRB.usrpb210.conf

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

T tracer was not functional anymore. because init_tpools() was called
before T_Config_Init().

The problem was that init_tpools() creates some threads and T_Config_Init()
does call fork() and the child process (which is the one running the
softmodem, the parent process is used to monitor it, this is the design
of the T tracer, maybe to change at some point, it's too complicated) has
no thread after the fork(). The threads created by init_tpools() are gone.
Game over.

In conclusion: T_Config_Init() has to be called very early in the life of
the softmodem, at least before init_tpools().