Virtual layer 1 - Questions

historical

Hi Sebastian,

On Tue, Feb 28, 2017 at 06:29:20PM +0100, Sebastian Stumpf wrote:

> I implemented the simple scheduler and it seems to work fine. I was happy
> to find the assignment of channels to their respective frame in the mframe
> in
> https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/mframe_sched.c#L67-L292
> and used that to calculate the fn the messages should be scheduled in.

good to hear.

> I come some steps further but are still having trouble to:
> 
> Send an sms to myself using the extension assigned to my ms from osmo-nitb
> (see 2341 in cap-file).
> VTY:
>  sms 1 12 "Hallo zusammen"
>  OsmocomBB#
>  % (MS 1)
>  % SMS to 12 failed: Semantically Incorrect Message

The establishment from 2341 looks fine:
* we first establish SAPI0 (signalling) on the SDCCH
* we then establish SAPI3 (SMS) on the same SDCCH (SABM/UA)
* we see The CP-DATA RP-DATA with the SMS-SUBMIT
* we get an CP-ACK from the network

Then the network tells us the SMS was semantically incorrect.  This is
a problem at a much higher level.  I would expect this to also be the
case if you used a real layer1 between an OsmocomBB phone and a BTS on
the network side.

from looking at the wireshark trace I cannot immediately identify an
issue.  I guess you need to 'logging enable sms debug' on the NITB and
see if it tells you where/why it fails.

> Call myself (11851 in cap file)
> VTY:
>  OsmocomBB# call 1 12
>  OsmocomBB#
>  % (MS 1)
>  % Call has been released

Ok, in 11445-11449 we see the RACH/CHAN_RQD/IMM.ASS, which assigns
Timeslot 7 to the MS.

In 11466 we see the CM SERV REQ on the Um inteface, in 11470 on the Abis
interface.

In 11470 we see the BSC responding with CM SERV ACC, in 11475 this is
forwaded over the Um inteface.

However, the MS never reacts to it.

Also, what's noteworthy (but likely unrelated) is that the BTS is
sending empty idle/padding frames on the TS7 all the time (those
containing 0x2b2b2b2b) but the MS is not doing that in uplink.

In 11546 the CM SERV REQ is re-transmitted in a SABM frame, which is
again acknowledged in the UA frame in 11548. So the BTS is doing
everything correctly (it seems) but the MS somehow doesn't receive the
UA (on LAPDm layer) nor the CM SERVICE ACCEPT (on layer 3 MM)

As you can see there is no RSL communication this time, as it is just
simply re-transmission on the LAPDm layer between BTS and MS.

> Losing RR connection after some time.

This is likely a result of the MS somehow not receiving/processing the
downlink signalling messages.

you could start a cell without any SDCCH to test if pure signalling
works on TCH/FACCH at all.  If you cannot even do a location update
anymore, the problem is in the TCH/FACCH receiving code.   If you can
perform LU over TCH, the problem becomes more mysterious ;)

> What I do not understand here is why I get a full power measurement request
> from mobile although I did set a fixed arfcn in the config.

maybe neighbor cell measurement reporting?

> And of course a fbsb req for arfcn 33578 seems simply wrong...

This is 0x832A which translates to ARFCN 810 decimal, with the highest
bit set for (if I remember correctly) PCS?  or Uplink/Downlink bit?  In
any case, the highest bit of the 16bit value is used for something else,
check the code :P

> Next step after fixing the false fbsb request from l23 would be to add a
> second mobile and then try to get the mobile originated call to work.

I think there's a problem with TCH/FACCH that needs to be resolved
first, see above.

But anyway, there's good progress and I'm happy you're pushing forward
with this!  I think a virtual L1 is a very useful foundation for all
kinds of automatic testing of the higher protocol layers, in a way that
everyone can execute, even without a real-world setup of BTSs and MSs.

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