we add a new STATE_TBF to vthe MS model and add some L1CTL primitives
to configure that TBF mode as well as to enqueue transmissions for
blocks at a given USF+TS.
Change-Id: Ie6f37090bd45f463aa25d9e00bc06f563be5264a
When we schedule a given frame for transmission, we save its timeslot
number. However, the callback doesn't get informed about this so far.
Change-Id: I608a91ae8e2a57a2d6f87f4b873c82edb0215bf6
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
The addresses in the original code make little sense:
* 224.0.0.1 is "All systems on this subnet" and not routed
outside the local ethernet segment
* 225.0.0.1 is in a RESERVED range that shouldn't be used
Change-Id: I8e3acd745e65a6cfa70b681a440da6a59a1ed0b5
We can avoid having to keep around the multicast group in a chunk of
dynamically allocated memory and simplify related code.
Change-Id: Ic39ffe73dfd2cb8ffefb9614340e275dac87bd50
We don't need to store this data, we cans simply connect the socket to
the destination mcast address instead.
Change-Id: I3c98653c41eff9feb649d9c47cd40b26fd81ed05
As of Change-Id Ie1bc00670887064da0fea61c3dab036c23ceea25, this function
is offered by libosmocore.
Change-Id: Ie269afe314967fd2c42b91ee854c217f699252dc
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
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
PCS flag was ignored in fbsb. Power management returned a perfect link
for all possible arfcns causing the mobile trying to sync to all these
afterwards. This took too long and PM now only returnes a good link
quality for arfcns configured as available.
Power management was also extracted to an own file.
Change-Id: Ia1b79aa47c9df3b1e316122455ceccb4a66724e0
As TCH is not supported in GSMTAP yet, all incoming frames on the
virt-phy are forwarded as FACCH to the l23 for now.
Cleanup code in virt_prim_data and virt_prim_traffic.
Change-Id: I6b41f21b6984e62ad98edfe4398bd678d5b2dad5
Proper calculation of the scheduled frame number and appending the jobs
with that fn to the scheduler. Thus uplink msgs are scheduled at the
(approx.) correct fn and with this fn set in the gsmtap hdr.
Change-Id: I0f44d0b5b9208755e671c619d1f851a043aefb54
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
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
Martin Hauke
Harald Welte
Sebastian Stumpf