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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Andreas, On Mon, May 03, 2010 at 12:47:59PM +0200, Andreas.Eversberg wrote: > tests with layer 3 pointed out a problem. when i select a cell, i get > updates of system informations, paging requests and immediate > assignments. > after about half an hour, i get some corrupt frames. i don't know yet what is > wrong. it might be that the oversimplified agc or afc code simply drifts away from the carrier. I've never used layer1 for that long so far, and I doubt somebody else has yet. Sorry :/ > 1. is the communication between the layer 1 and layer 2 (over serial > link) secure? well, as secure as any rs232 line is. there is no checksum on the rs232 (no-parity) and if ther is too much data than we can send at 115200, we have to drop frames. > 2. i must be sure that a message between layers always are: > - never get lost (except unit-data or data when connection is aborted) see above. > - never are corrupt see above (rs232) and below (Um interface) > - received in the order they are sent i don't think we can have re-ordering > 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it > should do) No, it does not. And this is quite intentional. We don't want to simply build a phone, but a generic tool to explore GSM networks and their protocols. E.g. in wireshark it might still be interesting to see such frames, even if they're known to have bit errors. However, what is not intentional, is that the number of bit errors (as computed by the DSP) is not yet passed up in the l1ctl header. This way, the higher layers could drop corrupted frames. This per-burst biterror information should be included in the l1ctl header and passed up. Cheers, 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)