Hi,
I further implemented the base of the virtual layer with the purpose of replacing the um-air interface with a multicast-socket solution. This has been started by Harald Welte some time ago in the Osmobts - laforge/virt-bts branch. As I was not really confident enough to create an official new branch before someone had a look on what I did, so I developed in copies of the osmocom-bb and osmo-bts projects on my github-page (https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts). If someone finds to time to have a look into them (structure, path, implementation) and give me feedback about it, I would be glad :). Please use the following config files that i have tested: - https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtua... - https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtua... - https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mob...
What works: BTS: - downlink over gsmtap and a multicast socket - OML and RSL on abis properly established and seems to work - virtual-um connection establishment Osmocom-bb: - virtual-um -- l23 app connection establishment (bridging osmocon, no serial link needed) - BCCH downlink handling and forwarding to l23 app - handling of some l1ctl requests from l23 (e.g. power management had to be mocked, so l23 gets a response and is satisfied)
What not: BTS: - missing uplink handling Osmocom-bb - missing uplink routines (RACH, TCH, dedicated channels) - handlers for l23 requests only partially implemented (missing TCH, RACH, ...
I a currently a bit overwhelmed by the mass of messages exchanged between l23-app (used mobile, btw.) and the virtual-um and hanging because mobile gets a sync timeout.
I am looking forward to hear from you :).
Sebastian Stumpf