Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Further investigation seems to indicate that nanoBTS only attempts connection *after receiving an OPSTART.

Which means we should NOT stay in Disabled Dependency, because then OPSTART is not going to be sent.

The objects which need to be kept as DisabledDependency while no RSL link exists are the NM CHannels (timeslots) above that BBTRANSC.
This way they cannot be opstarted until the RSL link is established.

I tested again and I confirm that nanoBTS doesn't attempt TCP connecting until it is sent the OPSTART command for the BBTRANSC object from the BSC.
Hence, IP address in RSL CONNECT message is not really tested because no TCP socket is created, and 0.0.0.0 is considered to be "use same remote address as per OML link) which is inherently valid since the OML link is up.

I also just checked: nanoBTS sends OPSTART ACK even before sending the TCP SYN to port 3003 (RSL), so yeah, it ACKs and then attempts creating the RSL socket, as I expected.

The real knowledge that the nanoBTS is prepared comes from the fact that it sends a StateChng Report to EnabledOk once it has a successful connect on the TCP/IPA/RSL link. That happens after the IPA handshake is successful apparently.

Hence, an important different we may want to take into account and change in osmo-bts: nanoBTS is creating the TCP/IPA/RSL socket upon receiving OPSTART, while we are creating it during RSL_CONNECT:

static int rx_oml_ipa_rsl_connect(struct gsm_bts *bts, struct msgb *msg,
                  const struct tlv_parsed *tp)
{
...
        trx->rsl_tei = stream_id;
        rc = e1inp_ipa_bts_rsl_connect_n(oml_link->ts->line, inet_ntoa(in), port, trx->nr);
...
}

Tested the patches above successfully with sysmobts and osmo-bts-trx.

Once merged we can close this ticket.