This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Andreas,
On Sun, Mar 10, 2013 at 12:41:10PM +0100, jolly wrote:
> hi harald,
> > http://cgit.osmocom.org/cgit/osmo-bts/commit/?h=jolly/trx&id=9be2099855532cff4313e132375c63c71fa8c0ff
> > looks fine to me, too, we should be able to merge that. My only comment
> > would be: Are you sure this should not be configured via OML from the
> > BSC? I think TS 12.21 Chapter 9.4.14 should be the proper way to
> > configure it. Do you agree? If yes, please use OML configuration and
> > remove the VTY option.
> >
> yes, i did not noticed that there is an OML IE for that. the specs leave
> open how to measure link at BTS side, so I decided to use same algorithm
> as the MS uses. (the MS gets initial value for radio link timeout via
> system information message.) i have just improved this patch (see
> jolly/trx branch).
Please note that the NM_ATT_CONN_FAIL_CRIT does not _have_ to be the
radio link timeout, i.e. just blindly dereferencing its value is wrong
in two parts:
1) it may be that the value part is not even two bytes long
2) it may be that the val[0] != 0x01, i.e. not RADIO_LINK_TIMEOUT
Please see my improved version of the patch in osmo-bts master
as commit 294fd1b650e4482775fdd604288fc928e66ef81c.
> i think that my branches are still quite experimental and not really
> made for merging yet.
I would like to avoid keeping the l1sap in a separate branch for too
long time as it will start to clash with other work that is being done.
So independent of the 'trx' branch, it would be good if we could get the
l1sap part into a state where you consider it worth merging at some
not too distant future. Thanks for offering to test + rebase
everything once you're done, though.
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)