This feature may be useful for our TTCN-3 testing infrastructure.
By default it's disabled, and can be enabled using command line
arguments of the main binary:
./trxcon -g 127.0.0.1 ...
Change-Id: Iab4128fee5f18d816830fdca6c5ebebaf7451902
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - it has nothing to do with xCCH coding. Instead, we need
to use rx_pdtch_fn() for Downlink and tx_rach_fn() for Uplink.
Also, since we only have a shared RSL channel number for PDCH
(Osmocom-specific RSL_CHAN_OSMO_PDCH), there should be a way
to distinguish both PDTCH and PTCCH logical channels. Let's
introduce TRX_CH_LID_PTCCH for that.
Change-Id: I2d1e9b8a66f027047f8d7bdc3f82ff9d8ebcc25e
Before using DATA_MSG.HDR_LEN, we need to make sure that a parsed
header version is known and supported. Otherwise we will get an
IndexError exception.
Change-Id: Ie1887aa8709da1a2a287aa58a7873e72c0b4ed33
Unlike DATA_MSG.HDR_LEN, the CHDR_LEN is a constant that defines
length of the common header, which is mandatory for every version.
DATA_MSG.HDR_LEN in its turn defines length of the whole header,
including the version specific fields. Thus we need to know the
header version before using it.
In DATA_MSG.parse_msg() we need to parse the common header first,
so then we know the version and length of the whole header. After
that we can safely use DATA_MSG.HDR_LEN.
Change-Id: I2809f5f96209eed64bdabf7a15575144313f7cc9
For sure, the following message is much more informative:
Ignoring an incorrect message: Unhandled version 12
than:
Failed to parse message, dropping...
NOTE: since the way of printing exceptions is different in both
Python versions, I had to drop Python 2 support.
Change-Id: I5fb02ce508c58ff94e47accc0ed655939eb53062
Raising exceptions is a Pythonic way to handle errors, which in this
particular case will help us to know *why* exactly a given message
is incorrect or incomplete.
Change-Id: Ia961f83c717066af61699c80536468392b8ce064
Both MG01GSMT and MG01GSMT hardware variants are
supported and automatically detected based on the
flash manufacturer.
Change-Id: I3a770ea93fc72c4e9b63078e253602f204b5be23
We now unlock the flash before reading the
extended ID (required for Spansion and Samsung
flash chips). These commands will be ignored
by Intel/ST flash chips, and this change has been
verified with all flash chips we support.
Furthermore, expose the API for reading the flash ID.
Change-Id: I3bcd71c84c8931bcd574953063737b51a41738a3
This commit adds polling of the TWL3025 PWON
signal. If the powerbutton is pressed on targets
that use it (Pirelli DP-L10, Huawei GTM900-B),
a normal keypad scanning cycle is started in order
to preserve the timing, required for the 500ms
power off press duration for example.
Change-Id: I904baf40d621bd680b602b88d12ff462b3c17596
This allows us to detect power button presses on the Pirelli
DP-L10 and the Huawei GTM900-B module. Polling will only be
activated once the power button has been pressed and we received
the interrupt. The goal is to reduce the required amount of
TWL3025 register accesses to a minimum.
Change-Id: I31be61c8089173aed616abd1ede6c4cf5c9b6770
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: I25baaa30b097dad2fae507c5321778f43e863611
Related: OS#4138
According to GSM TS 04.08, section 10.5.4.11, location and coding
standard are encoded before the cause value, not vice-versa!
Also, coding standards other than "1 1 - Standard defined for the
GSM PLMNs" shall not be used if the cause can be represented with
the GSM standardized coding.
Change-Id: Ic6abcfb9a9589f5b0c9c40def863f15ae04d0bdd
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the received one.
This change introduces a new command similar to FAKE_TOA and FAKE_RSSI,
so it can be used by TTCN-3 test case 'TC_pcu_data_ind_lqual_cb' to
verify that the link quality measurements are delivered to the PCU.
Change-Id: I7080effbbc1022d1884c6d6f0cb580eba8e514ff
Related: OS#1855
Messages on DATA interface may have different header formats, defined
by a version number, which can be negotiated on the control interface.
By default, the Transceiver will use the legacy header version (0).
The header format negotiation can be initiated by the L1 using the
'SETFORMAT' command. If the requested version is not supported by
the transceiver, status code of the response message should indicate
a preferred (basically, the latest) version. The format of this
message is the following:
L1 -> TRX: CMD SETFORMAT VER_REQ
L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ
where:
- VER_REQ is the requested version (suggested by the L1),
- VER_RSP is either the applied version if matches VER_REQ,
or a preferred version if VER_REQ is not supported.
If the transceiver indicates VER_RSP different than VER_REQ, the L1
is supposed to reinitiate the version negotiation using the suggested
VER_RSP. For example:
L1 -> TRX: CMD SETFORMAT 2
L1 <- TRX: RSP SETFORMAT 1 2
L1 -> TRX: CMD SETFORMAT 1
L1 <- TRX: RSP SETFORMAT 1 1
If no suitable VER_RSP is found, or the VER_REQ is incorrect,
the status code in the response shall be -1.
As soon as VER_RSP matches VER_REQ in the response, the process
of negotiation is complete. Changing the header version is
supposed to be done before POWERON, but can be also done after.
Change-Id: I8d441b2559863d2dbd680db371062e4f3a2f9ff9
Related: OS#4006
Since the new TRXD header format has been introduced, FakeTRX needs
to be able to fill it correctly. In particular, the following:
- Modulation, which can be determined from the burst length;
- Training Sequence Code (and set), which needs to be detected
by comparing the burst bits of L12TRX message against known
training sequences (only GMSK and the default TS set for now);
- C/I (Carrier-to-Interference ratio), which can be simulated
later on, as instructed on the TRXC interface ('FAKE_CI').
The actual TRXD header version is stored in the instance of class
DATAInterface. By default (at startup), legacy version 0 is used.
The version negotiation is supposed to be performed on the TRXC
interface, and to be implemented in a follow-up change.
Different Transceivers may use different header versions, thus in
FakeTRX.send_data_msg() we need to override the original version
of the L12TRX message, and generate the corresponding PDU.
Limitations:
- NOPE / IDLE indications are not (yet) supported;
- TSC detection: GMSK modulation only.
Change-Id: I164f5ae4ce7694d6e324aab927a04e96d489ebd8
Related: OS#4006
Training Sequences are defined in 3GPP TS 45.002, and used by the
transceiver for detecting bursts. This change introduces an enum
with training sequences for GMSK for Access and Normal bursts.
This enumeration is needed for the follow-up changes that implement
TRXD header version 1 support, and can now be used by RandBurstGen.
Change-Id: If3bf102019ef53d6ee9ad230ef98bb45845b5af5
Since version 0x01, the burst bits are encoded as L16V,
so appending two dummy octets doesn't make sense.
Change-Id: I4d6c0bf54649d636ea6cb3fa2f37486b6619d5b3
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
Change-Id: Ie810c5a482d1c908994e8cdd32a2ea641ae7cedd
Related: OS#4006, OS#1855
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers |
+-----------------+------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN. Therefore, the current header
format has implicit version 0x00.
Otherwise Wireshark (or trx_sniff.py) would need to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
The reserved bit number 3 can be used in the future to extend
the TDMA TN range to (0..15), in case anybody would need
to transfer UMTS bursts.
Change-Id: Idb0377d66290eb9c15d6998a5806a84fa2e5dd02
Related: OS#4006