hi,
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.
1. is the communication between the layer 1 and layer 2 (over serial link) secure? 2. i must be sure that a message between layers always are: - never get lost (except unit-data or data when connection is aborted) - never are corrupt - received in the order they are sent 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it should do)
andreas
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.
There is no timing regulation loop so it will loose alignement after a while. We see that with the racal.
Sylvain
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 :/
- 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.
- 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
- 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
baseband-devel@lists.osmocom.org