osmo-bts - branch:laforge/virt_phy - questions on virtual layer implementation

historical

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)