Hi,
The virtual layer 1 is currently in a state where the l23 app can
successfully connect to the bts and most of the signaling messages
will be forwarded and handled. TCH is not yet implemented.
I have some problems still, not knowing if these are caused by
configuration problems or my coding :).
- Trying to initiate a call via the mobile vty will result in
VTY:
call 1 123
OsmocomBB#
% (MS 1)
% Call has been rejected
call 1 123
OsmocomBB#
% (MS 1)
% Call has been released
And no actual call setup message is transfered over the Um interface.
What could be reasons for that? I am using the test-sim option the
mobile app offers.
- Occasionaly the T3210 timer is fired, which causes a new registering
within the network.
LOG:
gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired
How can i prevent that?
- I did not implement a tdma or multiframe scheduler in the mobile
uplink as the logical channel is directly put to the gsmtap-header and
thus known by the bts. As Harald used a multiframe based scheduling
for the bts downlink, i wonder if this might be necessary, though. To
submit msgs with the correct frame number for example.
- In my wireshark capture files, the gsmtap messages sent over the
multicast sockets are only recognized as UDP messages. I have to
"cast" them with the wireshark context menu "Decode as...". Why?
I would be super happy if someone of you could check out my project
(osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch
stumpf/virt-phy) try to run it with the config files lying within the
project folders and tell me the problems they see :).
Here you can find a wireshark capture file of 2 mobiles connecting to
a virt bts. I also tried to init calls from both of them but the call
setup is not send.
https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-…
Kind Regards,
Sebastian Stumpf
I have a general question about the Paging procedure, specifically about
how to stop paging.
In libbsc, we have Paging management that receives a request to Page from
the MSC and then repeatedly Pages the MS on all BTSes N times or until
told to stop.
In the NITB, we have code closely tied to the BSC and all BTS management,
so that when we receive a Paging Response, we can right away stop sending
Paging Commands on all BTSes.
So can the standalone-BSC: it stops paging when it received a Paging
Response.
In OsmoMSC with Iu- and A-interfaces, that's not possible. Looking in
08.08, there seems to be no A-interface message that tells the BSCs "thank
you, you can stop paging now". If one BSC or RNC has relayed back a Paging
Response from one of the cells, the MSC has no way to tell the other base
stations that it's fine to stop sending dozens of Pagings out for
"minutes", which would be useless now anyway because the MS has called
back via another base station already.
Is that a fact of life? We continue Paging in all cells where the MS is
not visible? Should the BSC/RNC part of the network page only once, so
that "stop paging" is a no-op?
Of course we first check which LAC the MS was first seen on and page only
there. Is the idea to send paging to one cell, and that cell stops Paging
by itself when it received a Paging Response that it relays to the MSC?
But IIRC Paging is supposed to spread out across other base stations if at
first it didn't succeed -- I recall to have read that in HNB-GW specs or
somewhere close to that. Our OsmoHNBGW so far simply Pages everywhere.
The practical reason I'm asking is that in the msc_vlr tests, I so far
explicitly check whether the "stop paging" function was called. Now on the
Iu branch, without libbsc, there is no such function. Should I drop those
checks because we will never have that? Or should I add some shim function
we call just for the tests so far, which will at some point tell the base
stations that Paging has concluded?
Thanks for any hints,
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
I currently have a whole series of patches on gerrit, many of which fail
to build. Here are the pivotal ones I am waiting for, the other patches
can be mostly ignored until these are through:
https://gerrit.osmocom.org/1682 (struct bsc_subscr)
Waiting for a comment. VLR and 3G branches build on it. I'm happy to
change the patch, but not sure whether I really have to. IMHO there are
benefits to this unusual way, but one word ("no") is enough.
https://gerrit.osmocom.org/1923 (cosmetic prep for 1924)
https://gerrit.osmocom.org/1924 (python tests: VTY connection speedup)
These two are needed for the openbsc python tests speedup patches to work.
https://gerrit.osmocom.org/1962 (explicitly terminate ctrl_type_vals[])
https://gerrit.osmocom.org/1940 (find unterminated value strings)
The first is a fixup for the second to work, the second one is needed for
all of the other value_string topic patches to work. I'd like to add this
check to jenkins now, so that all incoming value_string[]s are validated.
https://gerrit.osmocom.org/1906 (python tests from separate build dir)
I usually build 2G and 3G separately, and I'd like to run the py tests in
each dev cycle, now that they are faster. So I'd love to merge this.
Hope this helps to save some time...
~N