Hi Sebastian, On Sun, Feb 12, 2017 at 02:29:05PM +0100, Sebastian Stumpf wrote: this is excellent news! Thanks for sticking with this and pushing it forward. I'm not sure if this is the root cause, but it seems there is some timeslot mis-matches in your traces. The Immediate Assignment contains TS 2 or TS 7, but I see Uplink frames for FACH on TS0, which is impossible (TS0 never has a channel combination with FACCH). Also, The uplink frames don't have the Uplink bit set in the GSMTAP header. This is a bit confusing, and I think it would be a good idea to introduce some consistency/invariant checking on both sides, i.e. the BTS should drop all non-uplink frames received, and the MS should drop all uplink frames received. I'm also surprised to see you're seeing an immediate assignment reject in downlink. This should only happen if all channels are allocated and the BTS is out of resources. Also, in your traces, there are typically several frames that are on the same timeslot in the same GSM frame number. This is not possible (probably related to the wrong TS above?). At maximum, there can be one L2 signalling message for a given TS + FN. Also, on the real radio interface a MAC block takes typically four frames on that channel, so the actual rate is lower. well, it means that something got lost between MS and MSC for such a long time (between sending the LU REQ and receving a response) that the MS gives up. The underlying problem must be resolved. On the simulated L1 you shouldn't loose messages, so this shouldn't happen if all messages arrive as expected on both sides. It is primarily a question of how real the simulation should be. By using a multiframe scheduler one can make sure that the actual bandwidth/speed of GSM is maintained even over a virtual L1. Also, on the BTS side it must be present to schedule the BCCH (system information, ...) without which a MS would never even see the cell. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. This seems because you're using a non-standard port for the messages: In the capture I see UDP port 6666 rather than the IANA-registered port for GSMTAP which is 4729. I'll have a look, but not straight away now, sorry. Already the LU is not working stable, so I think the first step is to stabilize this. You can see in packet 740 that the MS is sneding a LU Req, which the BTS forwards in frame 741 as RSL message to the NITB. The NITB then responds with an IDENTITY REQUEST which can be seen on RSL but which seems to disappear in the BTS without being ever sent on the virtual Um interface. As a result, the MS never sends the identity response, and the NITB will give up. I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. Also, RACH retransmissions are happening way too quick. See Packets 600...644 where there are 7 RACH requests all within soemething like 10ms. The BTS then allocates 7 channels rather than one, ... So I think those lower-layer issues should be addressed before moving on to voice calls. Keep up the good work! 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)