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/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)