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