target/fake_trx: initial release of virtual transceiver
This is a set of tools for creating a virtual Um-interface between
OsmocomBB and OsmoBTS. It may be extremely useful for testing and
development of GSM stack, including both sides (MS and BTS). This
software implements OsmoTRX (Osmocom's fork of OpenBTS transceiver)
style clock (CLCK), control (CTRL) and data interfaces. So, OsmoBTS
source code doesn't require any modifications, while for OsmocomBB
you will need to use a new application - trxcon, which can be found
in the 'fixeria/sdr_phy' branch until one is merged to master.
Brief description of available applications:
- fake_trx.py - main application, that allows to connect both
OsmocomBB and OsmoBTS without actual RF hardware. Currently
only a single MS may work with a single BTS.
- clck_gen.py - a peripheral tool aimed to emulate TDMA frame
clock generator. Could be used for testing and clock
synchronization of multiple applications. It should be noted,
that one relays on generic system timer (via Python), so
a random clock jitter takes place.
- ctrl_cmd.py - another peripheral tool, which could be used
for sending CTRL commands directly in manual mode, and also
for application fuzzing.
Change-Id: Ib1fb80682002ac85a72fa6abef459a4c44f4ab97
2017-07-10 12:39:06 +00:00
|
|
|
# -*- coding: utf-8 -*-
|
|
|
|
|
|
2018-03-12 18:09:56 +00:00
|
|
|
# TRX Toolkit
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
# Burst forwarding between transceivers
|
target/fake_trx: initial release of virtual transceiver
This is a set of tools for creating a virtual Um-interface between
OsmocomBB and OsmoBTS. It may be extremely useful for testing and
development of GSM stack, including both sides (MS and BTS). This
software implements OsmoTRX (Osmocom's fork of OpenBTS transceiver)
style clock (CLCK), control (CTRL) and data interfaces. So, OsmoBTS
source code doesn't require any modifications, while for OsmocomBB
you will need to use a new application - trxcon, which can be found
in the 'fixeria/sdr_phy' branch until one is merged to master.
Brief description of available applications:
- fake_trx.py - main application, that allows to connect both
OsmocomBB and OsmoBTS without actual RF hardware. Currently
only a single MS may work with a single BTS.
- clck_gen.py - a peripheral tool aimed to emulate TDMA frame
clock generator. Could be used for testing and clock
synchronization of multiple applications. It should be noted,
that one relays on generic system timer (via Python), so
a random clock jitter takes place.
- ctrl_cmd.py - another peripheral tool, which could be used
for sending CTRL commands directly in manual mode, and also
for application fuzzing.
Change-Id: Ib1fb80682002ac85a72fa6abef459a4c44f4ab97
2017-07-10 12:39:06 +00:00
|
|
|
#
|
trx_toolkit/transceiver.py: add frequency hopping support
There are two ways to implement frequency hopping:
a) The Transceiver is configured with the hopping parameters, in
particular HSN, MAIO, and the list of ARFCNs (channels), so the
actual Rx/Tx frequencies are changed by the Transceiver itself
depending on the current TDMA frame number.
b) The L1 maintains several Transceivers (two or more), so each
instance is assigned one dedicated RF carrier frequency, and
hence the number of available hopping frequencies is equal to
the number of Transceivers. In this case, it's the task of
the L1 to commutate bursts between Transceivers (frequencies).
Variant a) is commonly known as "synthesizer frequency hopping"
whereas b) is known as "baseband frequency hopping".
For the MS side, a) is preferred, because a phone usually has only
one Transceiver (per RAT). On the other hand, b) is more suitable
for the BTS side, because it's relatively easy to implement and
there is no technical limitation on the amount of Transceivers.
FakeTRX obviously does support b) since multi-TRX feature has been
implemented, as well as a) by resolving UL/DL frequencies using a
preconfigured (by the L1) set of the hopping parameters. The later
can be enabled using the SETFH control command:
CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>]
where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz)
corresponding to one ARFCN the Mobile Allocation. Note that the
channel list is expected to be sorted in ascending order.
NOTE: in the current implementation, mode a) applies to the whole
Transceiver and all its timeslots, so using in for the BTS side
does not make any sense (imagine BCCH hopping together with DCCH).
Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
2020-05-14 10:03:25 +00:00
|
|
|
# (C) 2017-2020 by Vadim Yanitskiy <axilirator@gmail.com>
|
|
|
|
|
# Contributions by sysmocom - s.f.m.c. GmbH
|
target/fake_trx: initial release of virtual transceiver
This is a set of tools for creating a virtual Um-interface between
OsmocomBB and OsmoBTS. It may be extremely useful for testing and
development of GSM stack, including both sides (MS and BTS). This
software implements OsmoTRX (Osmocom's fork of OpenBTS transceiver)
style clock (CLCK), control (CTRL) and data interfaces. So, OsmoBTS
source code doesn't require any modifications, while for OsmocomBB
you will need to use a new application - trxcon, which can be found
in the 'fixeria/sdr_phy' branch until one is merged to master.
Brief description of available applications:
- fake_trx.py - main application, that allows to connect both
OsmocomBB and OsmoBTS without actual RF hardware. Currently
only a single MS may work with a single BTS.
- clck_gen.py - a peripheral tool aimed to emulate TDMA frame
clock generator. Could be used for testing and clock
synchronization of multiple applications. It should be noted,
that one relays on generic system timer (via Python), so
a random clock jitter takes place.
- ctrl_cmd.py - another peripheral tool, which could be used
for sending CTRL commands directly in manual mode, and also
for application fuzzing.
Change-Id: Ib1fb80682002ac85a72fa6abef459a4c44f4ab97
2017-07-10 12:39:06 +00:00
|
|
|
#
|
|
|
|
|
# All Rights Reserved
|
|
|
|
|
#
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
# (at your option) any later version.
|
|
|
|
|
#
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
|
#
|
|
|
|
|
# You should have received a copy of the GNU General Public License along
|
|
|
|
|
# with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
|
|
trx_toolkit: use generic logging module instead of print()
There are multiple advantages of using Python's logging module:
- advanced message formatting (file name, line number, etc.),
- multiple logging targets (e.g. stderr, file, socket),
- logging levels (e.g. DEBUG, INFO, ERROR),
- the pythonic way ;)
so, let's replace multiple print() calls by logging calls,
add use the following logging message format by default:
[%(levelname)s] %(filename)s:%(lineno)d %(message)s
Examples:
[INFO] ctrl_if_bts.py:57 Starting transceiver...
[DEBUG] clck_gen.py:87 IND CLOCK 26826
[DEBUG] ctrl_if_bts.py:71 Recv POWEROFF cmd
[INFO] ctrl_if_bts.py:73 Stopping transceiver...
[INFO] fake_trx.py:127 Shutting down...
Please note that there is no way to filter messages by logging
level yet. This is to be introduced soon, together with argparse.
Change-Id: I7fcafabafe8323b58990997a47afdd48b6d1f357
2018-12-06 22:00:26 +00:00
|
|
|
import logging as log
|
2018-02-27 00:00:45 +00:00
|
|
|
|
2020-07-11 11:45:21 +00:00
|
|
|
from trx_list import TRXList
|
|
|
|
|
|
|
|
|
|
class BurstForwarder(TRXList):
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
""" Performs burst forwarding between transceivers.
|
2018-12-06 00:23:08 +00:00
|
|
|
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
BurstForwarder distributes bursts between the list of given
|
|
|
|
|
FakeTRX (Transceiver) instances depending on the following
|
|
|
|
|
parameters of each transceiver:
|
2018-12-06 00:23:08 +00:00
|
|
|
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
- execution state (running or idle),
|
|
|
|
|
- actual RX / TX frequencies,
|
|
|
|
|
- list of active timeslots.
|
2018-12-06 00:23:08 +00:00
|
|
|
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
Each to be distributed L12TRX message is being transformed
|
|
|
|
|
into a TRX2L1 message, and then forwarded to transceivers
|
|
|
|
|
with partially initialized header. All uninitialized header
|
|
|
|
|
fields (such as rssi and toa256) shall be set by each
|
|
|
|
|
transceiver individually before sending towards the L1.
|
2018-12-06 00:23:08 +00:00
|
|
|
|
|
|
|
|
"""
|
2018-08-01 21:06:05 +00:00
|
|
|
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
def forward_msg(self, src_trx, rx_msg):
|
trx_toolkit/transceiver.py: add frequency hopping support
There are two ways to implement frequency hopping:
a) The Transceiver is configured with the hopping parameters, in
particular HSN, MAIO, and the list of ARFCNs (channels), so the
actual Rx/Tx frequencies are changed by the Transceiver itself
depending on the current TDMA frame number.
b) The L1 maintains several Transceivers (two or more), so each
instance is assigned one dedicated RF carrier frequency, and
hence the number of available hopping frequencies is equal to
the number of Transceivers. In this case, it's the task of
the L1 to commutate bursts between Transceivers (frequencies).
Variant a) is commonly known as "synthesizer frequency hopping"
whereas b) is known as "baseband frequency hopping".
For the MS side, a) is preferred, because a phone usually has only
one Transceiver (per RAT). On the other hand, b) is more suitable
for the BTS side, because it's relatively easy to implement and
there is no technical limitation on the amount of Transceivers.
FakeTRX obviously does support b) since multi-TRX feature has been
implemented, as well as a) by resolving UL/DL frequencies using a
preconfigured (by the L1) set of the hopping parameters. The later
can be enabled using the SETFH control command:
CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>]
where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz)
corresponding to one ARFCN the Mobile Allocation. Note that the
channel list is expected to be sorted in ascending order.
NOTE: in the current implementation, mode a) applies to the whole
Transceiver and all its timeslots, so using in for the BTS side
does not make any sense (imagine BCCH hopping together with DCCH).
Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
2020-05-14 10:03:25 +00:00
|
|
|
# Originating Transceiver may use frequency hopping,
|
|
|
|
|
# so let's precalculate its Tx frequency in advance
|
|
|
|
|
tx_freq = src_trx.get_tx_freq(rx_msg.fn)
|
|
|
|
|
|
2020-08-26 15:45:35 +00:00
|
|
|
if src_trx.rf_muted:
|
|
|
|
|
del rx_msg.burst # burst bits are omited
|
|
|
|
|
rx_msg.burst = None
|
|
|
|
|
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
# Iterate over all known transceivers
|
|
|
|
|
for trx in self.trx_list:
|
|
|
|
|
if trx == src_trx:
|
|
|
|
|
continue
|
|
|
|
|
|
|
|
|
|
# Check transceiver state
|
|
|
|
|
if not trx.running:
|
|
|
|
|
continue
|
2019-11-17 13:37:05 +00:00
|
|
|
if rx_msg.tn not in trx.ts_list:
|
trx_toolkit/fake_trx.py: refactor global class hierarchy
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
2018-12-10 10:39:51 +00:00
|
|
|
continue
|
|
|
|
|
|
trx_toolkit/transceiver.py: add frequency hopping support
There are two ways to implement frequency hopping:
a) The Transceiver is configured with the hopping parameters, in
particular HSN, MAIO, and the list of ARFCNs (channels), so the
actual Rx/Tx frequencies are changed by the Transceiver itself
depending on the current TDMA frame number.
b) The L1 maintains several Transceivers (two or more), so each
instance is assigned one dedicated RF carrier frequency, and
hence the number of available hopping frequencies is equal to
the number of Transceivers. In this case, it's the task of
the L1 to commutate bursts between Transceivers (frequencies).
Variant a) is commonly known as "synthesizer frequency hopping"
whereas b) is known as "baseband frequency hopping".
For the MS side, a) is preferred, because a phone usually has only
one Transceiver (per RAT). On the other hand, b) is more suitable
for the BTS side, because it's relatively easy to implement and
there is no technical limitation on the amount of Transceivers.
FakeTRX obviously does support b) since multi-TRX feature has been
implemented, as well as a) by resolving UL/DL frequencies using a
preconfigured (by the L1) set of the hopping parameters. The later
can be enabled using the SETFH control command:
CMD SETFH <HSN> <MAIO> <RXF1> <TXF1> [... <RXFN> <TXFN>]
where <RXFN> and <TXFN> is a pair of Rx/Tx frequencies (in kHz)
corresponding to one ARFCN the Mobile Allocation. Note that the
channel list is expected to be sorted in ascending order.
NOTE: in the current implementation, mode a) applies to the whole
Transceiver and all its timeslots, so using in for the BTS side
does not make any sense (imagine BCCH hopping together with DCCH).
Change-Id: I587e4f5da67c7b7f28e010ed46b24622c31a3fdd
2020-05-14 10:03:25 +00:00
|
|
|
# Match Tx/Rx frequencies of the both transceivers
|
|
|
|
|
if trx.get_rx_freq(rx_msg.fn) != tx_freq:
|
|
|
|
|
continue
|
|
|
|
|
|
2019-11-17 13:37:05 +00:00
|
|
|
# Transform from L12TRX to TRX2L1 and forward
|
|
|
|
|
tx_msg = rx_msg.gen_trx2l1(ver = trx.data_if._hdr_ver)
|
|
|
|
|
trx.handle_data_msg(src_trx, rx_msg, tx_msg)
|
