From b98c5d6c3405a6ce8df6904f6578cdee0f4279e2 Mon Sep 17 00:00:00 2001 From: Vadim Yanitskiy Date: Mon, 18 Jan 2021 18:14:18 +0100 Subject: TRXD: more information on PDU versioning and some highlights Change-Id: Idac4a1c73cc92bf030ea80474c71688bfb706421 Related: SYS#4895, OS#4941, OS#4006 --- common/chapters/trx_if.adoc | 50 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/common/chapters/trx_if.adoc b/common/chapters/trx_if.adoc index ef2740b..d1aa566 100644 --- a/common/chapters/trx_if.adoc +++ b/common/chapters/trx_if.adoc @@ -311,15 +311,16 @@ RSP SETSLOT HVHH C0/S1 C0/S1 C0/S2 NOTE: In the example for `HVHH`, legacy TCH/H0 does not belong to a _VAMOS pair_, so it can be configured to use any Training Sequence Code without restrictions. +[[trx_if_pdu_version_nego]] ==== TRXD header version negotiation -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). +Messages on DATA interface may have different 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). See <>. -The header format negotiation can be initiated by the BTS using `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) +The format negotiation can be initiated by the BTS using `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: ---- CMD SETFORMAT @@ -353,7 +354,38 @@ before `POWERON`, but can be also done afterwards. === TRXD protocol -Messages on the data interface carry one radio burst per UDP message. +PDUs on the data interface carry one radio burst per one UDP packet. +Two kinds of TRXD PDU exist: + +* `TRX -> L1` (from transceiver to the L1): Uplink messages received from the MS, +* `L1 -> TRX` (from the L1 to transceiver): Downlink messages sent to the MS. + +Depending on the origin and the version indicator, PDUs may have different structure. + +[[trx_if_pdu_versioning]] +==== PDU versioning + +The format of a PDU, i.e. presence and ordering of certain fields, is determined by +the version number indicated in the first octet. This is usually referred as +`TRXDvN`, where `N` is the version number (e.g. TRXDv0 or TRXDv1). A version number +indicates the message format to be used for both directions: `TRX -> L1` and +`L1 -> TRX`. The same version shall be used for all messages in both directions, +mixing in any way is not permitted. + +The version negotiation is optionally initiated by the `L1` on the control interface, +and expected to be performed before starting the transceiver (i.e. sending `POWERON` +command). See <>. + +The current header allows to distinguish up to 16 different versions. +The following versions are defined so far: + +* TRXDv0 - initial version of TRXD protocol, inherited as-is from OpenBTS project. +* TRXDv1 (proposed in July 2019): +** Introduced the concept of protocol versioning; +** Introduced NOPE / IDLE indications; +** New field: MTS (Modulation and Training Sequence); +** New field: C/I (Carrier-to-interface) ratio; +** Downlink messages mostly unchanged. ==== Uplink Data Burst @@ -417,7 +449,7 @@ padding existence is completely dropped. ---- VER: 4 bits:: -TRXD header version, v0 and v1 are specified so far. +TRXD header version, common for both `TRX -> L1` and `L1 -> TRX` directions. TN: 3 bits:: Timeslot number. @@ -542,7 +574,7 @@ the TSC set indicated by the preceding bits. ---- VER: 4 bits:: -TRXD header version, v0 and v1 are specified so far. +TRXD header version, common for both `TRX -> L1` and `L1 -> TRX` directions. TN: 3 bits:: Timeslot number. -- cgit v1.2.3