2 Jun
2016
2 Jun
'16
1:35 p.m.
Hi,
as a part of my master thesis I am currently trying to complete the
implementation of the virtual physical layer in the laforge/virt-bts
branch in osmo-bts.git.
I already set up the projects and analyzed/debugged some of the code.
Now I have a few things to ask or be confirmed by the pros :).
1. The sent messages on the virtual physical layer will be wrapped
in a GSM_TAP header. I would like to analyze and implement the Uplink
(MS->BTS) on the BTS side first, by sending dummy messages a small
program and then processing them in the BTS. Unfortunately I don't
have these dummy messages. Can anyone of you provide me with some
examples for the msgs coming from the MS side (Access Burst on RACH,
Uplink Burst on TCH, RSSI on SACCH, Location Update Request on SDCCH,
Authentication Response on SDCCH) or tell me how else I can get my
fingers on them?
2. Did I correctly understand that the virt_um_rcv_cb() method in
l1_id.c will unwrap incoming GSM_TAP messages and distribute/forward
them to layer2? Is the correct l2 interface to use l1sap.c from the
common part? E.g. l1sap_ph_rach_ind(..) for incoming RACH msg from MS.
3. Does any logic to unwrap and forward GSM_TAP messages already
exist or was that solely used for logging via wireshark by now.
4. I added some comments to the code, mostly to document my own
unterstandings. But as I am no expert yet, they might contain some
logical errors. Can I keep these in the code when commiting or better
remove them?
5. Should I create a new branch for my work (e.g. stumpf/virt_phy) or
commit to the existing?
Not so important Questions:
6. I had a compilation error caused by 2 missing methods in the
main.c.I added empty method bodies for
bts_model_phy_link_set_defaults(..) and
bts_model_phy_instance_set_defaults(..) and everything seems okay so
far. Can I do that or did I miss something here?
7. To check if I receive incoming messages from the registered
virtual UM multicast socket I periodically wrote a dummy text to it
with a small program. As the registered callback method
virt_um_rcvcb(..) wasn't called I checked the initialization of the
multicast socket (virtual_um.c->virt_um_init(..)). After some research
it seems that mcast sockets do not support a call of connect() after a
bind(). Removing the call that connects the socket to the multicast
group and port, seems to work. Is that okay or are there any problems
I could run into by not connecting to the mcast socket? I think
connect() is usally used on tcp sockets.
Thank you very much in advance for your answers!
Kind Regards,
Sebastian Stumpf
8 Jun
8 Jun
2:12 p.m.
Hi Sebastian,
you posted to the list without subscribing to it first, so your post was
stuck in the moderator queue, whcih only gets reviewd very unfrequently,
sorry.
On Thu, Jun 02, 2016 at 01:35:39PM +0200, Sebastian Stumpf wrote:
as a part of my master thesis I am currently trying to
complete the
implementation of the virtual physical layer in the laforge/virt-bts
branch in osmo-bts.git.
great!
1. The sent messages on the virtual physical layer
will be wrapped
in a GSM_TAP header. I would like to analyze and implement the Uplink
(MS->BTS) on the BTS side first, by sending dummy messages a small
program and then processing them in the BTS. Unfortunately I don't
have these dummy messages. Can anyone of you provide me with some
examples for the msgs coming from the MS side (Access Burst on RACH,
Uplink Burst on TCH, RSSI on SACCH, Location Update Request on SDCCH,
Authentication Response on SDCCH) or tell me how else I can get my
fingers on them?
I think rather than creating custom code to generate the messages for
testing, it makes more sense to modify OsmocomBB to generate the
required messages and send them over GSMTAP. Basically replace anything
below the L1CTL protocol of OsmocomBB with a virtual GSMTAP layer.
Encoding the messages is the simple part. Implementing all the protocol
logic and state machines on top of it is the hard part, and without that
it will be difficult to test osmo-bts-virtual.
Also, I would recommend to first complete the downlink path, i.e.
osmo-bts-virt downlink transmission into GSMTAP (should be thre more or
less already), and then add the receptionof downlink GSMTAP to
OsmocomBB. At some point, OsmocomBB should be able to detect your
virtual BTS just like it would detect a real BTS when used with a real
phone. From that point onwards, it will try to send RACH requesets and
establish a SDDCH for location update, and you can implement it step by
step.
2. Did I correctly understand that the
virt_um_rcv_cb() method in
l1_id.c will unwrap incoming GSM_TAP messages and distribute/forward
them to layer2?
yes.
Is the correct l2 interface to use l1sap.c from the
common part? E.g. l1sap_ph_rach_ind(..) for incoming RACH msg from MS.
yes.
3. Does any logic to unwrap and forward GSM_TAP
messages already
exist or was that solely used for logging via wireshark by now.
I don't think any GSMTAP parser/receiver outside wireshark exists so
far, sorry.
4. I added some comments to the code, mostly to
document my own
unterstandings. But as I am no expert yet, they might contain some
logical errors. Can I keep these in the code when commiting or better
remove them?
feel free to submit an 'add comments to the code' patch via gerrit
against master, and we will review it and (hopefully) merge it. This
patch/patchset should not introduce any logical changes, just contain
the comments.
5. Should I create a new branch for my work (e.g.
stumpf/virt_phy) or
commit to the existing?
I think the best strategy is to rebase the laforge/virt-bts on current
master, and then build your own branch on top of that.
6. I had a compilation error caused by 2 missing
methods in the
main.c.I added empty method bodies for
bts_model_phy_link_set_defaults(..) and
bts_model_phy_instance_set_defaults(..) and everything seems okay so
far. Can I do that or did I miss something here?
The two methods have been added to the phy_link abstraction betewen the
bts-model-* and commonpart after the laforge/virt-bts was created. You
can simply use empty functions for the time being, yes.
7. To check if I receive incoming messages from the
registered
virtual UM multicast socket I periodically wrote a dummy text to it
with a small program. As the registered callback method
virt_um_rcvcb(..) wasn't called I checked the initialization of the
multicast socket (virtual_um.c->virt_um_init(..)).
sorry to hear that. As indicated, I started with downlink first, and
the next logical step would have been on te OsmocomBB side, and I never
got further.
After some research it seems that mcast sockets do not
support a call
of connect() after a bind(). Removing the call that connects the
socket to the multicast group and port, seems to work. Is that okay or
are there any problems I could run into by not connecting to the mcast
socket?
It's been many years (probably about 15!) since I last wrote IP
multicast applications, so I didn't recall the detailed semantics,sorry.
Indeed your research seems right. So drop the connect().
I think connect() is usally used on tcp sockets.
it is equally usual to use it on UDP sockets, if yo have a stream
between two peers. If you don't conncet the socket, you cannot use
write/send/send, but you have to use sendto() and always pass the
destination address of the packet with every syscall, rather than
setting it once at time of stream establishment.
So I wanted to use the same logic for UDP multicast sockets, but
apparently that doesn't work, you thus probably have to use an explicit
sendto() for all frames, like for other unconnected UDP unicast
sockets, too.
Thank you very much in advance for your answers!
Thanks for working on this, looking forward to your patches!
--
- 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)
2886
days inactive
2892
days old
1 comments
2 participants
participants (2)
-
Harald Welte -
Sebastian Stumpf