csd_v110: set E2 bit correctly for TCH/[FH]4.8 NT (details)
CSD RTP: verify alignment of V.110 frames (details)
csd_v110_rtp_decode: preserve E2 & E3 bits for RLP alignment (details)
cosmetic: eliminate else-after-return in gsmtap_csd_rlp_process() (details)
cosmetic: move gsmtap_csd_rlp_process() to csd_rlp.c (details)
CSD NT modes: transmit properly aligned RLP frames on DL (details)
Commit
59686cd276e0ec6d0f173c36e9c708fd73560463
by falcon
CSD: implement half-rate modes correctly
TCH/H4.8 and TCH/H2.4 modes are different from all other TCH in that the channel coder runs (statistically) every 40 ms instead of the usual 20 ms. However, the standard RTP interface of TS 48.103 still requires 20 ms packets for all CSD modes; furtherfore, this requirement is not just a matter of 3GPP spec being obstinent, but is highly useful for interoperability, both between FR and HR and between OsmoBTS and E1 BTS.
The handling of CSD HR was totally broken in this regard: wrong RA2 packing mode, RTP clock model was violated, and even an internal mismatch with l1sap sending TCH.req prims at twice the rate at which the PHY expects them.
With this patch CSD HR handling becomes correct for TCH/H2.4 and for TCH/H4.8 transparent; fully correct handling for TCH/H4.8 NT will appear in a follow-up patch.
The packet/frame rate mismatch (40 ms Rx/Tx times while each RTP packet carries 20 ms worth of data) is reconciled by emitting two RTP packets directly back-to-back for UL, and pulling two RTP packets at a time from the Rx jitter buffer at the needed times for DL.
Note: due to bug OS#6604, TTCN3 tests for CSD half-rate transparent modes will start failing once this patch is merged; to make them pass again, TTCN3 test code will need to be reworked to fix that bug.
Commit
c40e75277fbbb32963096197a8926bd9fc0a11d6
by falcon
csd_v110: set E2 bit correctly for TCH/[FH]4.8 NT
In all classic NT modes below 14.5 kbit/s, V.110 frame bits E2 and E3 are repurposed to indicate the alignment whereby a single 240-bit RLP frame is composed of 4 pseudo-V.110 frames in switching transport. (TS 48.020 section 15.1.) In the case of TCH/F9.6, setting both E2 and E3 is easy because all 4 pseudo-V.110 frames go out in the same clearmode RTP packet as a result of a single channel decoding operation. However, in the case of TCH/F4.8 there are two separate channel decoding operations producing two separate RTP packets 20 ms apart. Furthermore, GSM 05.03 section 3.4.1 specifies which TDMA frame positions hold which half of the RLP frame - therefore, the correct emission of bit E2 needs to be based on the TDMA frame number at which the block was received.
A similar situation occurs with TCH/H4.8 NT: we receive a single block from the 05.03 decoder every 40 ms, containing a full RLP frame, but we emit it as two separate RTP packets, each carrying 20 ms worth of bits. These RTP packets also require correct setting of E2 bit.
Commit
414e1ca8edb7d2169183d2129775f28140ee6bd8
by falcon
CSD RTP: verify alignment of V.110 frames
Since the beginning of CSD implementation, OsmoBTS has operated with an implicit (unstated) policy that V.110 frames must be perfectly aligned within received clearmode RTP packets - a requirement which is NOT set anywhere in TS 48.103 or any of the other specs it references. This design policy is sensible from the standpoint of implementation complexity (both OsmoBTS and osmo_trau2rtp emit such perfectly aligned packets; if someone is building a gateway between an Osmocom GSM network and ISDN-style external networks, that gateway can act as the aligner), but it should be explicit rather than implicit.
Check V.110 frame alignment in received clearmode RTP packets, and reject packets that fail this alignment check.
Commit
5bed286c6c08426e1cc74fbd9c83033c773f718d
by falcon
csd_v110_rtp_decode: preserve E2 & E3 bits for RLP alignment
Modify CSD RTP input path code so incoming bits E2 & E3 from V.110 frames reach the TCH-RTS.ind handler in l1sap. These bits will be used in the next patch to ensure proper alignment of DL RLP frames in non-transparent CSD modes.
Commit
7accf7579daa8c14c00ae9f61bee7a3625a0b31e
by falcon
cosmetic: eliminate else-after-return in gsmtap_csd_rlp_process()
The code in this function used else-after-return constructs, which are now rejected by the linter for newly committed code. This function needs to be moved to a new source file, which will cause it to be treated as new code by the linter - hence fix this code style issue first.
Commit
02951e4af3284276b2e4abdd707fdf374be5233f
by falcon
cosmetic: move gsmtap_csd_rlp_process() to csd_rlp.c
The next patch in the series will add code for alignment of downlink RLP frames in CSD NT modes; that code will go into new file csd_rlp.c. RLP GSMTAP code logically belongs in the same place - hence move it there in preparation.
Commit
0a34af1530760bb6b69173f31bfd47cfe62ab002
by falcon
CSD NT modes: transmit properly aligned RLP frames on DL
There are two levels of alignment inside clearmode RTP packets carrying CSData per TS 48.103 section 5.6:
1) Alignment of 2 or 4 V.110 (T) or pseudo-V.110 (NT) frames within one RTP packet of 160 octets of an imaginary ISDN B channel;
2) For NT modes only, alignment of 4 pseudo-V.110 frames to form a single 240-bit RLP frame.
Per previous patch, alignment 1 is to be treated as mandatory for RTP transport inside an Osmocom network. Alignment 2 _could_ be made mandatory for TCH/F9.6 NT, but the same is not possible for TCH/[FH]4.8 NT: in the best case of half-alignment, alternating RTP packets will carry alternating halves of RLP frames.
Implemented solution: allow arbitrary state of alignment 2 (aligned or misaligned) in the incoming RTP stream for all CSD NT modes, and perform the necessary alignment internally.
This approach is consistent with the world of E1 BTS: a TRAU in data mode is responsible for alignment 1 (with 20 ms TRAU frames taking the place of our clearmode RTP packets), but only the BTS can perform alignment 2, as the TRAU is agnostic to T vs NT distinction.