Holger Hans Peter Freyther wrote:
hi holger,
What does that it mean? What was the result of the test? What was the content of the test. "I tested it" is a sentence without any content. ;)
i setup a UmTRX with two transceivers and used the jolly/trx_rebased branch to develop and test this patch. then i made calls on timeslots of different TRX, to see if the correct RSL connection is used to handle the channel. RSL connections on both TRX worked.
if (link->ofd->priv_nr >= E1INP_SIGN_RSL)trx_nr = link->ofd->priv_nr - E1INP_SIGN_RSL;e1i_ts = &link->line->ts[link->ofd->priv_nr-1];Where does this difference come from?
the priv_nr is set to E1INP_SIGN_OML (1) or E1INP_SIGN_RSL+trx_nr (2..). in order to retrieve the trx_nr from priv_nr, i substract E1INP_SIGN_RSL. the priv_nr is also the index for selecting the ts structure. because we do not have a physical E1 line, we can use ts[0] also, so '1' is substracted.
What are the alternatives to this patch? Can we copy the cfg.ipa fields into a per RSL line field and set the trx_id there before the first time we use it?
i looked at the data structure. the ipaccess_unit structure, which is linked to cfg.ipa.dev could be removed. instead we could provide individual ipaccess_unit structure per RSL/OML link. when calling e1inp_ipa_bts_rsl_connect(), we could provide a pointer to the individual structure. this pointer must be stored inside ipa_client_conn structure then.
alternatively we could provide an array of ipaccess_unit, instead of a single structure and attach it to cfg.ipa.dev.
in both cases, the BTS code must care of filling the ipaccess_unit structures with data for OML and each RSL link.
regards,
andreas