TRX version transmits dummy FACCH instead of proper downlink BFIs
In speech TCH operation, there will always be times when a speech frame needs to be transmitted on the downlink, but there is no frame available to transmit (gap in the incoming RTP stream), or the logic of DTXd (FR/HR/EFR) says that no frame shall be transmitted at this FN, but we are not doing physical DTXd. The common layer of OsmoBTS indicates such conditions to the BTS model by sending TCH.req primitive with no attached message, and osmo-bts-sysmo version passes the problem to the proprietary PHY by sending it a zero-length payload. But what should we do in the 100% DIY TRX version?
The current code in osmo-bts-trx transmits dummy FACCH under these conditions. This approach is OK for TCH/F, even if not ideal philosophically, but is bad for TCH/H: if we have one missing 20 ms frame, we would like to transmit a filler block (one that will cause a BFI condition in the MS receiver) just in that one 20 ms position, rather than take out a 40 ms block-pair with FACCH/H.
For FR, HR and EFR speech codecs this patch implements a better solution, transmitting invalid speech blocks with inverted CRC3 instead of dummy FACCH:
However, the case of AMR speech is still left unfixed (transmitting dummy FACCH, including the bad case of FACCH/H on TCH/AHS), and I (falconia) am not currently qualified to implement whatever proper solution is needed for AMR. That proper solution for AMR would need to be implemented by someone who has studied AMR and thoroughly understands it as well as I have studied and now understand FR/EFR and HRv1, and being a community network operator contributing to Osmocom in conjunction with said network operation, rather than a paid developer, I do not currently have a time budget to get into AMR to the depth I would consider necessary. Therefore, the present ticket will need to remain open after the above patch gets merged, until whenever some AMR-knowledgeable developer gets the necessary time allocation to fix the bug for AMR speech.
- TCH/FS, TCH/EFS
- TCH/AFS, TCH/AHS
- Status changed from New to In Progress
I looked at the code and the TS 45.003. For me a solution would be similar to EFR/FR. I would poison and empty frame (with inverse the remainder of the CRC bits). (Also it must not confuse with the DTX controling frames.) There location of the CRC bits are almost different for all 8 codec rates and one is different between AFS and AHS.
In the first place I thought about sending DTX frames instead, but this is wrong. The phone must extrapolate the gap on bad frames, not insert silence or some kind of comfort noise.