Hello All,
We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.
When Dynamic TCH tested with the old BSC commit version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.
Please let us know if it is known issue.
Thanks and Regards, Mrinal
Dear Mrinal,
please be aware that TCH/F_PDCH is a pchan type that is designed for use with ip.access nanoBTS exclusively. This BTS model understands a non-standard RSL message to de-/activate PDCH ("PDCH Act"). Some of our other BTS software also support this pchan kind: sysmoBTS, lc15 and osmo-bts-trx if I remember correctly, but preferably use the pchan type TCH/F_TCH/H_PDCH in your osmo-bsc or osmo-nitb config.
When you refer to a PS call, do you mean that GPRS service is used to place a VoIP call? This is the same as saying that GPRS is functional.
There should be no significant difference in functionality concerning dynamic timeslots (either kind) between master and commit 7bc6986f6ba, all commits that "really matter" concerning dyn TS were already present in that revision.
Please verify your statements and/or accompany with log output, and also try TCH/F_TCH/H_PDCH instead.
If the problem persists, please a) bisect to pinpoint the failing revision and b) add full log output, preferably with DRSL and DNM logs set to debug level.
I verified that TCH/F_TCH/H_PDCH is functional on sysmobts with all the newest commits just yesterday.
~Neels
On Fri, Nov 11, 2016 at 12:51:03PM +0000, Mrinal Mishra wrote:
Hello All,
We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.
When Dynamic TCH tested with the old BSC commit version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.
Please let us know if it is known issue.
Thanks and Regards, Mrinal
From: Neels Hofmeyr [mailto:nhofmeyr@sysmocom.de]
I remember correctly, but preferably use the pchan type TCH/F_TCH/H_PDCH in your osmo-bsc or osmo-nitb config.
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.
When you refer to a PS call, do you mean that GPRS service is used to place a VoIP call? This is the same as saying that GPRS is functional.
By PS call I mean GPRS data transfer and yes GPRS is functional.
Please verify your statements and/or accompany with log output, and also try TCH/F_TCH/H_PDCH instead.
I have tested TCH/F_TCH/H_PDCH also and it works fine as TCH/H channel. As per the name of the pchan type it can be used as TCH/F or TCH/H or PDCH But it does not work as TCH/F. Also as I mentioned earlier in TCH/F_PDCH pchan type CS (voice) call does not work.
If the problem persists, please a) bisect to pinpoint the failing revision and b) add full log output, preferably with DRSL and DNM logs set to debug level.
Currently I am busy in other activities. I will bisect and capture the logs once I have some time . Could you please suggest any specific Unit test case which can be executed to compare result.
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
On Mon, Nov 14, 2016 at 5:42 PM, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
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.
The reason why people use TCH/F is because it offers higher quality than TCH/H. E.g. if you're using AMR, you can go only up to 7.95 mode in TCH/H (see https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec). So just saying that TCH/H is "more efficient" is not correct. It's more efficient in exchange to some loss in quality.
On Mon, Nov 14, 2016 at 07:59:16PM -0800, Alexander Chemeris wrote:
The reason why people use TCH/F is because it offers higher quality than TCH/H. E.g. if you're using AMR, you can go only up to 7.95 mode in TCH/H (see https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec). So just saying that TCH/H is "more efficient" is not correct. It's more efficient in exchange to some loss in quality.
IMHO twice the number of timeslots qualifies for saying "more efficiently using the available timeslots" :)
But thanks for this clarification. My impression so far was that AMR on TCH/H has fair enough quality that the voice call experience isn't noticeably different to TCH/F and "everyone is using it anyways"...?
Also how do "people use" TCH/F? Is it a choice the MS user is able to make? Or is this always a choice on the CN side?
~N
From: Neels Hofmeyr [mailto:nhofmeyr@sysmocom.de]
IMHO twice the number of timeslots qualifies for saying "more efficiently
I meant twice the number of voice lchans, of course.
I have tested the CS voice call using 1 TCH/H channel in osmo-bts-trx using USRP B210 board and CS voice call was not successful. When I configure 2 TCH/H channel in the TRX then CS voice call works fine. BSC commit version used was " 87ef68eb33d463d8aad1511a272cbdb779f1ba19" As per your explanation 1 TCH/H channel is sufficient for 1 CS voice call( Mobile originated and Mobile terminated CS call). Please correct me if I am wrong.
Thanks and Regards, Mrinal
On Tue, Nov 15, 2016 at 03:01:55PM +0000, Mrinal Mishra wrote:
As per your explanation 1 TCH/H channel is sufficient for 1 CS voice call( Mobile originated and Mobile terminated CS call). Please correct me if I am wrong.
Please be aware of https://osmocom.org/issues/1795 If you have time to investigate and/or fix, that would be highly appreciated.
~Neels
On Tue, Nov 15, 2016 at 10:32:59AM +0100, Neels Hofmeyr wrote:
But thanks for this clarification. My impression so far was that AMR on TCH/H has fair enough quality that the voice call experience isn't noticeably different to TCH/F and "everyone is using it anyways"...?
this is true. the concern is primarily about handsets too old to support AMR, so they would only be able to do HRv1. And that is really crappy. So on such handsets, you typically try to fall back to TCH/F.
At least whenever I did traces here in Berlin with German operators, it was pretty standard that AMR/HR was used at all time [with phones that support it], irrespective on which Operator.
Also how do "people use" TCH/F? Is it a choice the MS user is able to make? Or is this always a choice on the CN side?
please see the various discussions and tickets on codec selection.
* the MS reports its codec capability * the BTS has a codec capability * the BSC and MSC/MGW might have codec capabilities * there is operator policy involved
so you need to find the common codec sub-set accross all components in the path, and then take operator policy into consideration, as well as current channel load in the cell, etc.
-
Alexander Chemeris -
Harald Welte -
Mrinal Mishra -
Neels Hofmeyr