Dear all,
osmo-gsm-tester is currently capable of setting up an entire network with one or more BTSs, Modems, NITB, etc. and test signaling + SMS.
Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that
a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel.
Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_1440...) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_1012...) before.
The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop.
So if we can activate that loop-back functionality from the Osmocom stack, we could test if we get back the same voice data that we send in downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS).
Regards, Harald
On Mon, May 29, 2017 at 03:29:49PM +0200, Harald Welte wrote:
Voice testing has always been on the wishlist, but further down on the TODO list. One issue here is that
a) many modems don't do voice at all (data-only modems for laptops) b) some modems expose voice only as analog audio (difficult to interface, would require custom hardware next to the modem, e.g. using USB soundcard, calibrate the levels, ...) c) some modems expose the voice as PCM bus. Similarly, would require some external codec chip and/or USB soundcard or the like, plus a custom circuit d) some modems expose voice as "GSM codec frames over UART" or other highty proprietary formats e) some modems expose voice as USB audio device. Most convenient, but only found in some Qualcomm LE based devices such as Sierra Wireless or Quectel.
For the record, Harald already knows this: Another issue is that we don't have a modem yet for which ofono offers even the possibility of initiating a call. It would be nice to at first have the voice signalling to begin with.
simpler: Every phone is supposed to include a voice loop-back mode. In
Hah interesting feat! I wonder whether it is sending the exact RTP packets back. This way we can certainly play around with the RF attenuation and see whether voice frames got dropped and so forth.
Sounds like we would initiate a single-leg call from the MSC with the modem in loopback mode. But we could maybe also still call one modem from the other, and tell one of them to go in loopback mode? Anyhow, sounds quite interesting.
The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop.
Hopefully we can tell the sysmoUSIM to do this, and thus still use all other features like authentication?
downlink (minus some occasional bit error, but those should be super low given we're operating omso-gsm-tester over coaxial cabling between MS and BTS).
Unless we do want to turn up the attenuation and see how, say, handovers go.
~N
On 5/29/17, Harald Welte laforge@gnumonks.org wrote:
d) some modems expose voice as "GSM codec frames over UART"
You got me curious here: are there any modems out there other than FreeCalypso that offer the quoted special feature? Someone actually paid me to add this special feature to FreeCalypso a little over a year ago, so I reason that it must be sufficiently non-standard that they couldn't find a commercial off-the-shelf modem that can do this feat.
M~
Hi Mychaela,
On Mon, May 29, 2017 at 12:21:38PM -0800, Mychaela Falconia wrote:
On 5/29/17, Harald Welte laforge@gnumonks.org wrote:
d) some modems expose voice as "GSM codec frames over UART"
You got me curious here: are there any modems out there other than FreeCalypso that offer the quoted special feature? Someone actually paid me to add this special feature to FreeCalypso a little over a year ago, so I reason that it must be sufficiently non-standard that they couldn't find a commercial off-the-shelf modem that can do this feat.
I've definitely seen this in commercial modems.
If I remember correctly, it was the Gemalto EHS-6, which can disable the GPS uart and re-cycle that UART for the audio frames. It might also have been a Quectel UC-20. Now that I think more about it, I think it was the UC-20.
On 30. May 2017, at 08:23, Harald Welte laforge@gnumonks.org wrote:
Hi Mychaela,
If I remember correctly, it was the Gemalto EHS-6, which can disable the GPS uart and re-cycle that UART for the audio frames. It might also have been a Quectel UC-20. Now that I think more about it, I think it was the UC-20.
Yes UC-20, with 40ms (according to the documentation not 20ms!) of audio at a time. I have used gstreamer with the filebin to send audio and cat+ audacity to receive it.
holger
Holger Freyther holger@freyther.de wrote:
Yes UC-20, with 40ms (according to the documentation not 20ms!) of audio at a time. I have used gstreamer with the filebin to send audio and cat+ audacity to receive it.
What exactly are the bits which you send and receive every 40 ms? Do you get two 260-bit GSM 06.10 codec frames every 40 ms, with the ability to send your own arbitrary bits into the TCH uplink, including the possibility of passing non-speech data over voice TCH if the network does TFO as in GSM 02.53? The latter is what the Calypso DSP allows.
M~
On 30. May 2017, at 09:43, Mychaela Falconia mychaela.falconia@gmail.com wrote:
Holger Freyther holger@freyther.de wrote:
Hi
What exactly are the bits which you send and receive every 40 ms? Do you get two 260-bit GSM 06.10 codec frames every 40 ms, with the ability to send your own arbitrary bits into the TCH uplink, including the possibility of passing non-speech data over voice TCH if the network does TFO as in GSM 02.53? The latter is what the Calypso DSP allows.
It is alaw. I assume the Qualcomm DSP will do the transcoding but I didn't look/trace the implementation (and the UC20 doesn't run Linux).
E.g. I used this to play a sine wave on a connected call.
gst-launch-1.0 audiotestsrc wave=sine ! audioconvert ! audioresample ! audio/x-raw, rate=8000, channels=1, format=S16LE ! filesink location=/dev/ttyUSB1 sync=true
Hi all,
On Mon, May 29, 2017 at 03:29:49PM +0200, Harald Welte wrote:
Over the weekend I was thinking of yet another method to make this much simpler: Every phone is supposed to include a voice loop-back mode. In this mode, the phone siply loops back all voice frames received in the downlink and sends them back in the uplink. This functionality is mandatory by the spec, and used to test the receiver performance of the phone during development, manufacturing and service. IT is specified in 3GPP TS 44.014 (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_1440...) which used to be GSM TS 04.04 (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_1012...) before.
The idea is that one puts a special "Test SIM" (as specified in TS 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this context) into the phone, and then sends some specific commands on Layer3 to activate the loop.
I have now produced such a "test sim". It's as easy as to update the firsrt byte of EF.AD with 0x80, e.g. using the following APDU (after authorizing with proper credentials like ADM1 pin and selecting EF.AD): 00d60000048000ff02
I also have an experimental branch[1] of OsmoNITB which can send the loopback commands. And at least with a K800i I also get an acknowledgement.
* first start a silent call to establish a dedicated TCH subscriber imsi 262423203000003 silent-call start tch/f
* then send the CLOSE_TCH_LOOP command with loop type A subscriber imsi 262423203000003 ms-test close-loop a
* OsmoNITB reports success: <0002> gsm_04_14.c:129 FIXME: Received TEST class message 'CLOSE_TCH_LOOP_ACK'
I haven't actually tried yet to see if the voice channel is actually looped back. But at least the results look promising so far.
Regards, Harald
[1] http://git.osmocom.org/openbsc/log/?h=laforge/ts_04_14
On Mon, Jun 12, 2017 at 01:55:52AM +0200, Harald Welte wrote:
- first start a silent call to establish a dedicated TCH
subscriber imsi 262423203000003 silent-call start tch/f
- then send the CLOSE_TCH_LOOP command with loop type A
subscriber imsi 262423203000003 ms-test close-loop a
- OsmoNITB reports success:
<0002> gsm_04_14.c:129 FIXME: Received TEST class message 'CLOSE_TCH_LOOP_ACK'
Nice. And apparently we don't even need ofono to do any voice call signalling for it.
~N
-
Harald Welte -
Holger Freyther -
Mychaela Falconia -
Neels Hofmeyr