Hi 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=9be2099855…
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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)