* Build up the usual include directory hierarchy.
* Move l1ctl_proto.h to 'include/osmocom/bb/'.
* System headers first, then libosmo*, the local ones.
Change-Id: I25145630ec53c2b8065a42fb12a778eec010f10c
Related: OS#5500
This allows us to bind the multicast sockets to a given network device
and/or to set the TTL of the multicast frames and hence control their
reach in terms of number of network hops.
Change-Id: Ia74aa381a4c1921cb8c7e263842a864ea8028139
Related: OS#2966
The files are used in both projects, and while the osmo-bts code has
evolved, this copy didn't. Let's sync again (to libosmocore
change-Id I303f2e616d2d32b5a8005c3dcf0f5fad19ad3445).
Change-Id: I189ee28a85a6d7a7a07b062f6b07012478503e8f
Depends: libosmocore.git Ib52d22710020b56965aefcef09bde8247ace4a9c
Related: OS#2966
There is no helptext for the commandline options, which makes it
difficult for new users to use the program.
- Add commandline help
Change-Id: I8d04644342acd64432742f96e32dc9f2e0e91c20
We make sure that all allocations are tracked back to one talloc root
context, and install the usual SIGUSR1 handler to dump the talloc
report. This enables us to do interactive debugging for memory leaks
while virtphy is running.
Change-Id: I73b3cf86eea5f56595c1b045cf0fde8035ff185a
This will basically only print L1C message for all L1CTL happening
between MS and the BTS, while suppressing the GSMTAP/virtUM and L1P
related messages.
Change-Id: I9513db3cee12644ed9b9858e13b740ffd27aba24
L1 Data is quite verbose, while control is typically limited, so let's
make sure we log them as separate sub-systems
Change-Id: Idebc371a63508c593855486ff01b2ba6e8c2cfd1
Now that we can have multiple MS connected to one virtphy instance,
it is important to log some context whenever possible. To do so, we
introduce a monotonically increasing MS number which gets assigned
whenever we allocate a l1_model_ms and printed when the LOGPMS() or
DEBUGPMS() macros are used.
Change-Id: Id7d9507126a03def5bd7690f1dbe987f9a749e65
* l1_model_ms can become a static member of l1_model_ms
* crypto_info_ms can become a static member of l1_state_ms
Change-Id: I94ca4dad1c6c668ce6307d5e5d728b1c1502af12
This is the result of my manual clean-up of the many coding style issues
found in the stumpf/virt-phy branch of OsmocomBB. Some may remain, but
it's much closer to what we're used to in the Osmocom world now.
Change-Id: I3aa95dbef75d7749d490aad0237d074528527e8b
Model was expanded and holds now power management information consisting
of an array of received power levels for all arfcns and one for the
reduction of this signal in dbm. The reduction is configurable by
commandline by --arfcn-sig-lev-red 666,12:888,13. The signal level is
assumed to be max level (-63) if a packet from that arfcn is received
within a timeframe (also configurable via cmd -- timeout-pm 5:800 ==
<seconds>:<microseconds>). After that timeout it will be reduced to min
level (-110).
Change-Id: I369ca26703f14bba4e9334b8f417deef640462f9
Available options:
dl-rx-grp: mcast group messages on downlink are received from
ul-tx-grp: mcast group messages on uplink are sent to
port: port used for mcast sockets
log-mask: logging mask
l1ctl-sock: l1ctl socket path to connect to l23
Change-Id: Id939e5d7b90b592c85ad19f3ad6f459351e2d8f6
Messages incoming on dedicated channel (SDCCH/8, SDCCH/4) are no longer
forwarded to l23 if their timeslot/subchannel is not fitting the ones
configured by l23 via L1CTL_DM_EST_REQ.
Change-Id: I6112b20e31c25636e53d3a6cda6f7443a94ff9c3
Msgs are not put on virt um directly in the handler like before, but are
scheduled. FN they are scheduled with not yet properly calculated.
Also, code was extracted from lactl_sap.c into own files.
Change-Id: Ibe57abebadf294f1407d82cef3fd0b51e7c1b23e
Implemented simple scheduler depending on frame number in downlink. It
will be executed each time we receive a msg on downlink and send out all
scheduled uplink msgs with a sched_fn smaller than the one of this
received downlink msg.
Further refactored l1ctl_sap by extracting rach and fbsb logic and
putting it to own files virt_prim_fbsb.c and virt_prim_rach.c
Added simple states to the ms layer 1 model, indicating if the ms is
currently searching for bts, syncing to or camping on a bts. Downlink
will be handled differently dependent of the state.
Change-Id: I8937b1d6568f5d3750bbdc5d77fa283074d5365e
Fixed mapping from gsmtap msg type to rsl msg type and vice versa.
Proper chan_nr decoding instead of usage of dummy values for timeslot /
link_id / subslot.
Implemented missing l23 rx handler routines.
Change-Id: Ibad741d112643c55091b8ba00164b05d728ae1a1
This patch implements a virtual physical layer replacing the air
interface. The purpose is to get rid of the hardware requirements
and be able to start testing and implementing layer 2 communication
functionality on one machine. Multicast sockets are used to enable
bidirectional communication between the BTS and the MS process.
The GSMTAP protocol designed for wireshark capturing is used to
encapsulate the payload on the virtual physical layer.
The virtual physical layer on the osmocom-bb side implements the
L1CTL interface to the layer23 apps like mobile.
* Working mcast socket communication and extraction of its
functionality.
* Basic handlers for file descriptor callbacks from incoming L1CTL
messages and extraction of that functionality to a l1ctl socket class.
* Multiplexing to different routines depending on incoming L1CTL
message type.
* Uses virt_um and osmocom_mcast_sock implementation from osmo-bts
virt-phy.
* Ecapsulation and parsing methods to and from GSMTAP messages.
* Basic handlers for file descriptor callbacks from incoming mcast
messages on the virtual um.
* Multiplexing to different channel routines based on GSMTAP header
channel type.
* Example configuration for l23 app mobile using virtual test sim.
Change-Id: I203c8ec58326e52a09603a37232fce7ae3641415
Vadim Yanitskiy
Harald Welte
Philipp Maier
Sebastian Stumpf