This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
pespin gerrit-no-reply at lists.osmocom.orgpespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/14940 Change subject: common: trx_if.adoc: Add documentation about TRXDv1 and SETFORMAT ...................................................................... common: trx_if.adoc: Add documentation about TRXDv1 and SETFORMAT Change-Id: I320539fc9ffb7dd0f09ec18892299bd603cd7a85 --- M common/chapters/trx_if.adoc 1 file changed, 139 insertions(+), 7 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/40/14940/1 diff --git a/common/chapters/trx_if.adoc b/common/chapters/trx_if.adoc index 0dda0f0..58d0f49 100644 --- a/common/chapters/trx_if.adoc +++ b/common/chapters/trx_if.adoc @@ -141,20 +141,63 @@ |13| PDTCH+PACCH+PTCCH |=== +==== 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). + +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) +version. The format of this message is the following: +---- +CMD SETFORMAT <timeslot> <ver_req> +RSP SETFORMAT <ver_resp> <ver_req> +---- + +where: +* `<ver_req>` is the requested version (suggested by the BTS), +* `<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 BTS is +supposed to re-initiate the version negotiation using the suggested `<ver_rsp>`. +For example: + +---- + BTS -> TRX: CMD SETFORMAT 2 + BTS <- TRX: RSP SETFORMAT 1 2 + + BTS -> TRX: CMD SETFORMAT 1 + BTS <- 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 afterwards. + === TRXD protocol Messages on the data interface carry one radio burst per UDP message. ==== Uplink Data Burst -.TRXD Uplink data burst message structure +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. + +.TRXDv0 Uplink data burst message structure [packetdiag] ---- { colwidth = 32 node_height = 40 - 0-3: VER + 0-3: VER(0) 4: RES 5-7: TN 8-39: FN @@ -165,8 +208,27 @@ } ---- +.TRXDv1 Uplink data burst message structure +[packetdiag] +---- +{ + colwidth = 32 + node_height = 40 + + 0-3: VER(1) + 4: RES + 5-7: TN + 8-39: FN + 40-47: RSSI + 48-55: TOA256 + 56-63: MTS + 64-71: C/I + 72-127: ...Payload... +} +---- + VER: 4 bits:: -TRXD header version, shall be 0. +TRXD header version, v0 and v1 are specified so far. TN: 3 bits:: Timeslot number. @@ -184,13 +246,83 @@ TOA256: 8 bits (1 byte):: Timing of Arrival in units of 1/256 of symbol, big endian. +MTS: 8 bits (1 byte):: +Contains the Modulation and Training Sequence information. See <<coding-mts>> +for more information on the encoding. + +C/I: 16 bits (2 bytes):: +Contains the Carrier-to-Interference ratio in centiBels, big endian. The C/I +value is computed from the training sequence of each burst, where the "ideal" +training sequence can be compared with the actual training sequence and then +express that in centiBels. + Payload: 148 bytes for GSM, 444 bytes for EDGE:: -Contains the uplink burst. Soft symbol estimates, 0 -> definite "0", 255 -> -definite "1". +Contains the uplink burst. Unlike the downlink bursts, the uplink bursts are +designated using the soft-bits notation, so the receiver can indicate its +assurance from 0 to -127 that a given bit is 1, and from 0 to +127 that a given +bit is 0. The Viterbi algorithm allows to approximate the original sequence of +hard-bits (1 or 0) using these values. Each soft-bit (-127..127) of the burst is +encoded as an unsigned value in range (0..255) respectively using the constant +shift. This way: +* 0 -> definite "0" +* 255 -> definite "1". PAD: 2 bits (optional):: Padding at the end, historical reasons (OpenBTS inheritance). Bits can take any -value, but 0 is preferred. +value, but 0 is preferred. Only expected on TRXDv0 headers. + +[[coding-mts]] +===== 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). + +.MTS field structure +---- ++-----------------+---------------------------------------+ +| 7 6 5 4 3 2 1 0 | bit numbers (value range) | ++-----------------+---------------------------------------+ +| X . . . . . . . | IDLE / nope frame indication (0 or 1) | ++-----------------+---------------------------------------+ +| . X X X X . . . | Modulation, TS set number (see below) | ++-----------------+---------------------------------------+ +| . . . . . X X X | Training Sequence Code (0..7) | ++-----------------+---------------------------------------+ +---- + +IDLE / nope frame indication:: +The bit number 7 (MSB) is set to high when either nothing has been detected, or +during IDLE frames, so noise levels can be delivered, and avoid clock gaps on +the BTS side. Other bits are ignored, and should be set to low (`0`) in this +case. + +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 synchronization sequences. + +.Modulation and TS set number +---- ++-----------------+---------------------------------------+ +| 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) | ++-----------------+---------------------------------------+ +---- + +Training Sequence Code:: +The Training Sequence Code used to decode the burst. ==== Downlink Data Burst @@ -211,7 +343,7 @@ ---- VER: 4 bits:: -TRXD header version, shall be 0. +TRXD header version, v0 and v1 are specified so far. TN: 3 bits:: Timeslot number. -- To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/14940 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: I320539fc9ffb7dd0f09ec18892299bd603cd7a85 Gerrit-Change-Number: 14940 Gerrit-PatchSet: 1 Gerrit-Owner: pespin <pespin at sysmocom.de> Gerrit-MessageType: newchange -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190725/bdbde41e/attachment.htm>