Change in osmo-gsm-manuals[master]: TRXD: add documentation for TRXDv2 protocol

fixeria gerrit-no-reply at lists.osmocom.org
Fri Apr 16 15:01:43 UTC 2021


fixeria has submitted this change. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867 )

Change subject: TRXD: add documentation for TRXDv2 protocol
......................................................................

TRXD: add documentation for TRXDv2 protocol

Change-Id: I03b2beeb535848b31fd629ba3cd330b43072c08b
Related: SYS#4895, OS#4941, OS#4006
---
M common/chapters/trx_if.adoc
1 file changed, 257 insertions(+), 8 deletions(-)

Approvals:
  Jenkins Builder: Verified
  osmith: Looks good to me, but someone else must approve
  pespin: Looks good to me, but someone else must approve
  fixeria: Looks good to me, approved



diff --git a/common/chapters/trx_if.adoc b/common/chapters/trx_if.adoc
index fb9e99f..f4884f0 100644
--- a/common/chapters/trx_if.adoc
+++ b/common/chapters/trx_if.adoc
@@ -22,6 +22,10 @@
 
 The corresponding interface for every socket is at `P+100` on the BTS side.
 
+NOTE: Starting from TRXDv2, it's possible to use only one socket for all
+channels.  In this case, the global `TRXD` interface for all channels shall
+be established on port `P=B+1`.  See <<trx_if_pdu_batching>> for more details.
+
 [[trx_if_clock_ind]]
 === Indications on the Master Clock Interface
 
@@ -358,8 +362,8 @@
 
 === TRXD protocol
 
-PDUs on the data interface carry one radio burst per one UDP packet.
-Two kinds of TRXD PDU exist:
+Messages on the data interface carry one or optionally multiple radio bursts
+(see <<trx_if_pdu_batching>>) per one UDP datagram.  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.
@@ -390,12 +394,20 @@
 ** New field: MTS (Modulation and Training Sequence);
 ** New field: C/I (Carrier-to-interface) ratio;
 ** Downlink messages mostly unchanged.
+* TRXDv2 (proposed in January 2021):
+** Introduced the concept of burst batching (many bursts in one message);
+** Changed the field ordering (facilitating aligned access);
+** New field: batching indicator;
+** New field: TRX number;
+** New field: SCPIR for VAMOS.
 
-==== Uplink Data Burst
+==== Uplink PDU format
 
-Uplink data burst message structure differs from version 0 to 1. Basically,
-version 1 contains an extended header with regards to version 0, and the final
-padding existence is completely dropped.
+An Uplink TRXD PDU contains a demodulated burst with the associated measurements
+(signal strength, timing delay, etc.) and TDMA frame/timeslot number.  Starting
+from TRXDv1, a PDU may contain no payload, indicating the upper layers that the
+transceiver was not able to demodulate a burst (e.g. due to bad signal quality
+or the lack of signal during IDLE TDMA frames).
 
 .TRXDv0 Uplink data burst message structure
 [packetdiag]
@@ -452,6 +464,48 @@
 }
 ----
 
+.TRXDv2 Uplink message structure
+[packetdiag]
+----
+{
+	colwidth = 32
+	node_height = 40
+
+	0-3:	VER(2)
+	4:	RFU
+	5-7:	TN
+	8:	BATCH
+	9:	RFU
+	10-15:	TRXN
+	16-23:	MTS
+	24-31:	RSSI
+	32-47:	TOA256
+	48-63:	C/I
+	64-95:	FN
+	96-127:	Soft-bits
+}
+----
+
+.TRXDv2 Uplink message structure (batched part)
+[packetdiag]
+----
+{
+	colwidth = 32
+	node_height = 40
+
+	0-4:	RFU
+	5-7:	TN
+	8:	BATCH
+	9:	RFU
+	10-15:	TRXN
+	16-23:	MTS
+	24-31:	RSSI
+	32-47:	TOA256
+	48-63:	C/I
+	64-95:	Soft-bits
+}
+----
+
 VER: 4 bits::
 TRXD header version, common for both `TRX -> L1` and `L1 -> TRX` directions.
 
@@ -462,6 +516,12 @@
 Reserved for Future Use.  The sending side of the PDU shall set all bits to
 {bit-zero};  the receiving side shall ignore `RFU` fields.
 
+BATCH: 1 bit::
+This bit indicates whether a batched PDU follows (see <<trx_if_pdu_batching>>).
+
+TRXN: 6 bits::
+The transceiver (PHY channel) number this PDU is coming from.
+
 FN: 32 bits (4 bytes)::
 GSM frame number, big endian.
 
@@ -562,7 +622,7 @@
 
 ==== Downlink Data Burst
 
-.TRXD Downlink data burst message structure
+.TRXDv0 and TRXDv1 Downlink data burst message structure
 [packetdiag]
 ----
 {
@@ -578,6 +638,48 @@
 }
 ----
 
+.TRXDv2 Downlink data burst message structure
+[packetdiag]
+----
+{
+	colwidth = 32
+	node_height = 40
+
+	0-3:	VER(2)
+	4:	RFU
+	5-7:	TN
+	8:	BATCH
+	9:	RFU
+	10-15:	TRXN
+	16-23:	MTS
+	24-31:	PWR
+	32-39:	SCPIR
+	40-63:	RFU
+	64-95:	FN
+	96-127:	Hard-bits
+}
+----
+
+.TRXDv2 Downlink PDU structure (batched part)
+[packetdiag]
+----
+{
+	colwidth = 32
+	node_height = 40
+
+	0-4:	RFU
+	5-7:	TN
+	8:	BATCH
+	9:	RFU
+	10-15:	TRXN
+	16-23:	MTS
+	24-31:	PWR
+	32-39:	SCPIR
+	40-63:	RFU
+	64-95:	Hard-bits
+}
+----
+
 VER: 4 bits::
 TRXD header version, common for both `TRX -> L1` and `L1 -> TRX` directions.
 
@@ -585,7 +687,18 @@
 Timeslot number.
 
 RFU: variable bit-length::
-Reserved for Future Use, all bits shall be set to low (`0`).
+Reserved for Future Use.  The sending side of the PDU shall set all bits to
+{bit-zero};  the receiving side shall ignore `RFU` fields.
+
+BATCH: 1 bit::
+This bit indicates whether a batched PDU follows (see <<trx_if_pdu_batching>>).
+
+TRXN: 6 bits::
+The transceiver (PHY channel) number this PDU is addressed to.
+
+MTS: 8 bits (1 byte)::
+Contains the Modulation and Training Sequence information. See <<coding-mts>>
+for more information on the encoding.
 
 FN: 32 bits (4 bytes)::
 GSM frame number, big endian.
@@ -595,6 +708,142 @@
 in dB.  The absolute value is set on the control interface, so the resulting
 power is calculated as follows: `full_scale - (absolute_red + relative_red)`.
 
+SCPIR: 8 bits (1 byte)::
+SCPIR (Subchannel Power Imbalance Ratio) - the ratio of power between Q and I
+channels for a VAMOS pair.  This field shall be present when `MTC` field
+indicates the use of `AQPSK` modulation.  Otherwise, all bits shall be set
+to {bit-zero}.  The value is a signed integer with a valid range: -10..10 dB.
+
 Hard-bits: 148 x N bytes (variable length, N defined by modulation type)::
 Contains the downlink burst. Each hard-bit (1 or 0) of the burst is represented
 using one byte (0x01 or 0x00 respectively).
+
+[[trx_if_pdu_batching]]
+==== PDU batching
+
+Starting from TRXDv2, it's possible to combine several PDUs into a single
+datagram - this is called _PDU batching_.  The purpose of _PDU batching_
+is to reduce socket load and eliminate possible PDU reordering, especially
+in a multi-TRX setup.
+
+All _batched PDUs_ in a datagram must belong to the same TDMA frame number
+indicated in the first part.  The ordering of PDUs in a datagram may be
+different from the examples below, however it's recommended to batch PDUs
+in ascending order determined by TDMA timeslot number and/or `TRXN`.
+
+The following PDU combinations in a datagram are possible:
+
+* `a)` one datagram contains PDUs with the same TDMA timeslot number for all
+transceivers (total N PDUs per a TDMA timeslot);
+* one datagram contains complete TDMA frame with PDUs for all 8 timeslots:
+** `b)` either for a single transceiver (total 8 PDUs per a TDMA frame),
+** `c)` or for all transceivers (total 8 x N PDUs per a TDMA frame).
+
+None of these combinations are mandatory to support.
+
+NOTE: Automatic negotiation of the batching algorithm(s) is not yet specified.
+Currently both sides need to be manually configured to use _PDU batching_.
+
+NOTE: Size of the biggest possible TRXD datagram should be less than the
+_MTU (Maximum Transmission Unit)_ of the network interface connecting
+both BTS and the transceiver.  Otherwise the datagram is split across
+multiple IP packets, which may negatively affect performance.
+
+.Example: datagram structure for combination a)
+----
++--------+----------------+---------+------------------------+
+| TRXN=0 | TDMA FN=F TN=T | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=1 | TDMA FN=F TN=T | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=2 | TDMA FN=F TN=T | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=T | BATCH=0 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+----
+
+.Example: datagram structure for combination b)
+----
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+----
+
+.Example: datagram structure for combination c)
+----
++--------+----------------+---------+------------------------+
+| TRXN=0 | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=0 | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=0 | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=6 | BATCH=1 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits        |
++--------+----------------+---------+------------------------+
+----
+
+[[trx_if_pdu_vamos]]
+==== Coding of VAMOS PDUs
+
+In VAMOS mode, the throughput of a cell is increased by multiplexing two subscribers
+on a single TDMA timeslot.  Basically, *two* bursts are getting transmitted during
+one TDMA timeslot period, and both of them need delivered over the TRXD interface.
+
+In the Downlink direction, the two bursts belonging to a _VAMOS pair_ shall be
+concatenated together and sent in one TRXD PDU.  The resulting hard-bit sequence
+shall *not* be interleaved: `V0(0..147) + V1(0..147)` (296 hard-bits total), i.e.
+one complete burst for subscriber `V0` takes the first 148 bytes, and another
+complete burst for subscriber `V1` takes the remaining 148 bytes.  The `MTS` field
+shall indicate the use of `AQPSK` modulation, and the `SCPIR` field shall indicate
+the Power Imbalance Ratio between `V0` and `V1`.
+
+.Example: Downlink datagram containing a VAMOS PDU
+----
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+-----------+---------------------------------------+
+| TRXN=N | TDMA FN=F TN=T | Mod=AQPSK | Hard-bits: V0(0..147) + V1(0..147)    |
++--------+----------------+-----------+---------------------------------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----
+
+In the Uplink direction though, one or even both of the two bursts may be lost
+(e.g. due to high noise figures), so they shall always be sent in two separate
+PDUs.  The missing bursts shall be substituted by NOPE indications, so it's
+always a pair of _batched PDUs_.  The `MTS` field shall indicate the use of
+`GMSK` modulation.
+
+.Example: Uplink datagram containing batched VAMOS PDUs (both present)
+----
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+----------+----------------------------------------+
+| TRXN=N | TDMA FN=F TN=T | Mod=GMSK | Soft-bits for V0 (148 bytes)           |
++--------+----------------+----------+----------------------------------------+
+| TRXN=N | TDMA FN=F TN=T | Mod=GMSK | Soft-bits for V1 (148 bytes)           |
++--------+----------------+----------+----------------------------------------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----
+
+.Example: Uplink datagram containing batched VAMOS PDUs (one lost)
+----
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++--------+----------------+----------+----------------------------------------+
+| TRXN=N | TDMA FN=F TN=T | Mod=GMSK | Soft-bits for V0 (148 bytes)           |
++--------+----------------+----------+----------------------------------------+
+| TRXN=N | TDMA FN=F TN=T | NOPE.ind |
++--------+----------------+----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-gsm-manuals
Gerrit-Branch: master
Gerrit-Change-Id: I03b2beeb535848b31fd629ba3cd330b43072c08b
Gerrit-Change-Number: 22867
Gerrit-PatchSet: 11
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: osmith <osmith at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210416/886cbd18/attachment.htm>


More information about the gerrit-log mailing list