I see cells

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.org
Mon May 3 12:29:49 UTC 2010

Hi 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.

- 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)

More information about the baseband-devel mailing list