On Mon, Nov 14, 2016 at 02:55:30PM +0000, Mrinal Mishra wrote:
As per the channel configuration defined in the code TCH/F_PDCH is a valid channel configuration and it should work as TCH/F or PDCH channel dynamically. I tested even with TCH/F_TCH/H_PDCH and it works fine only as TCH/H or PDCH it does not get used as TCH/F.
I am glad to hear that TCH/F_TCH/H_PDCH works as TCH/H. The reason why this pchan type is not used as TCH/F is OS#1778 https://osmocom.org/issues/1778
Fixing OS#1778 is not a top priority at the moment. The perspective that TCH/H is more efficiently using the available timeslots than TCH/F and the fact that most MS are capable of TCH/H makes this not very urgent.
Since the ip.access nanoBTS is not capable of TCH/H, it is pretty much the only hardware where you actually want to use TCH/F_PDCH. Nevertheless, if TCH/F_PDCH is broken for other BTS models that support it, it should be fixed.
Also as I mentioned earlier in TCH/F_PDCH pchan type CS (voice) call does not work.
Of course TCH/F_PDCH is a valid channel configuration, which you may use if you insist on TCH/F -- as long as it is implemented for your BTS model. There is no unit test available. Testing pchan types involves using a NITB and actual BTS hardware. At some point, we would like to test this in our osmo-gsm-tester setup, which still needs a lot of work. See: https://osmocom.org/projects/cellular-infrastructure/wiki/Roadmap#Build-and-...
Kindly state which BTS hardware you are using. And I am looking forward to your logs and/or bisect, if you can spare the time.
As always, let me plug the possibility of directly sponsoring any of above mentioned issues via sysmocom, to anyone reading this and interested in quick progress.
~Neels