Hello Vadim,
I'm working on the TTCN3 tests for OsmoPCU. Harald told me, that there are a few tests existing tests (such as TC_ul_tbf), that had been developed with osmo-bts-virtual/virt_phy.
He also said that since there is trxcon/fake_trx nowadays, it would be better to use that instead, if it supports PDCH. From a quick "git grep", it looks like PDCH is supported in trxcon.
What do you think, should it work well enough to do the switch?
Thanks, Oliver
Hi Oliver,
I'm working on the TTCN3 tests for OsmoPCU.
great!
He also said that since there is trxcon/fake_trx nowadays, it would be better to use that instead, if it supports PDCH.
Well, I wouldn't say better. It depends what do you need to test. With the virt_phy, you can test the higher layers of OsmoBTS, so you are not affected by potential problems / bugs of particular L1 implementation, such as osmo-bts-trx.
With fake_trx.py and trxcon you can test the whole stack, including the L1 implementation (scheduling, convolutional coding, etc.). As a bonus, you can simulate different parameters of the virtual radio interface, including RSSI, ToA256, C/I, and even BER.
From a quick "git grep", it looks like PDCH is supported in trxcon.
Yep, it does. You can find the multiframe layout of PDCH:
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_mframe.c#n1811
which contains two logical channels:
PDTCH - Packet Data Traffic Channel, and PTCCH - Packet Timing advance Control Channel.
Neither in OsmoBTS nor in trxcon PTCCH is handled correctly:
https://osmocom.org/issues/4102
but PDTCH is implemented, please see:
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_desc.c#n... https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_pdtch.c
Currently there is only one TTCN-3 test case that uses PDTCH support in trxcon - f_TC_pcu_data_ind_lqual_cb:
https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn#n4320
The main problem is that trxcon has a bit different philosophy when it comes to packet data and PDCH in particular. Its early development was mostly influenced by OsmoBTS, and at that time I knew almost nothing about GPRS and its PHY.
One big difference from virt_phy is that trxcon uses different L1CTL messages: L1CTL_TRAFFIC_{REQ,CONF,IND} instead of L1CTL_DATA_{REQ,CONF,IND}. I don't insist on this, but IMHO this kind of message is better for PDTCH.
Another important detail is that there is no such thing as TBF flow in trxcon. Everything that was received on PDTCH will be forwarded to the higher layers, so they need to do TBF filtering themselves.
Ideally, we need to be able to configure one or more TBFs (using TFI), so trxcon would filter received packets. In virt_phy this can be done using L1CTL_TBF_CFG_{REQ,CONF}. At the same time, I would like to keep the possibility to receive everything for sniffing ;)
Finally, there is no way to ask trxcon to send a given Uplink block on particular TDMA frame number. Instead, a queued block will be sent almost immediately.
Resuming the above, we need to solve at least three problems:
1) L1CTL_TRAFFIC_{REQ,CONF,IND} vs L1CTL_DATA_{REQ,CONF,IND}; 2) Downlink TBF flow control: L1CTL_TBF_CFG_{REQ,CONF}; 3) Uplink TBF flow control: L1CTL_DATA_TBF_{REQ,CONF}.
While writing this mail, I've got an idea about a potential solution of the 1st one. We can just keep L1CTL_TRAFFIC_{REQ,CONF,IND} for the 'flowless' control (i.e. Rx/Tx everything regardless of TBFs), and implement L1CTL_DATA_{REQ,CONF,IND} handling for selective reception and transmission. Switching between the both modes can be done one reception of L1CTL_TBF_CFG_REQ.
I am open for the further discussion. Added Harald to CC.
With best regards, Vadim Yanitskiy.
Hi Vadim,
thank you very much for your in-depth answer!
Well, I wouldn't say better. It depends what do you need to test.
It is planned to test the following: * UL TBF * DL TBF * Paging * Timing Advance * Link Adaptation * Timer (Idle/Ready/...)
But as I'm just diving into this, I'll get the existing but disabled (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests running first. I'll start with virt_phy for now, and then see how far I can get with it.
Cheers, Oliver
On Mon, Jul 29, 2019 at 10:50:12AM +0200, Oliver Smith wrote:
Hi Vadim,
thank you very much for your in-depth answer!
Thanks also from my side. Given that the amount of resources we have for writing PCU tests is rather limited, I would suggest Oliver to stay with virt_phy for now and focus on the actual PCU tests and not on building required infrastructure.
In general, I still believe that for a "normal" MS behavior (whether in a test case or not), it is best to have some TBF state inside the L1 and filter the TFI there. Otherwise L2 just gets swamped with lots of messages that aren't interesting for it, and will just clog up logs, consume CPU (thinking of a real MS), ...
But as I'm just diving into this, I'll get the existing but disabled (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests running first. I'll start with virt_phy for now, and then see how far I can get with it.
The tests you mentioned were passing at some point. Of course our TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since, so there may be some fall-out :(
Hello Harald and Vadim,
On 7/29/19 8:42 PM, Harald Welte wrote:
Thanks also from my side. Given that the amount of resources we have for writing PCU tests is rather limited, I would suggest Oliver to stay with virt_phy for now and focus on the actual PCU tests and not on building required infrastructure.
Sounds good.
But as I'm just diving into this, I'll get the existing but disabled (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests running first. I'll start with virt_phy for now, and then see how far I can get with it.
The tests you mentioned were passing at some point. Of course our TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since, so there may be some fall-out :(
It is great that they were already passing in the past. Harald, do you happen to still have the configs around for running these two tests?
I am trying to piece it together, and so far I have the following. It would be great if you could point out any misconceptions I have.
The raw PCU tests, that are currently running in Jenkins, only start OsmoPCU and the testsuite. When doing the same for TC_ul_tbf and TC_ul_tbf_single_llc_sizes, the testsuite fails to establish the BSSGP connection:
MTC@gsmdevel: Test case TC_ul_tbf finished. Verdict: fail reason: Timeout establishing BSSGP connection
(This is confusing me a bit, isn't the Gp connection between the SGSN and GGSN according to [1]? But I am assuming, that this means the Gb connection towards the PCU.)
Looking at the osmo-pcu log, I find that it won't do anything (not accept connections) until it successfully connects to /tmp/pcu_bts.
I am starting osmo-bts-virtual in order to provide /tmp/pcu_bts. The socket appears, but it will also not properly start up until it connects to something via A-bis OML. So I am also starting osmo-bsc to provide that (I have looked at ttcn3-bts-test, which does it the same way).
Now osmo-bts-virtual is connecting to osmo-bsc, but osmo-bsc is dropping the connection immediately for some reason. Probably a mismatch in the configs, though at least the unit id is matching.
My current understanding is, that the following components need to run:
osmo-pcu | | /tmp/pcu_bts | osmo-bts-virtual ---A-bis OML--- osmo-bsc | | ? | virt_phy | | /tmp/osmocom_l2 | testsuite
Is that accurate? How does the connection between osmo-bts-virtual and virt_phy work?
Thanks, Oliver
Forgot to add the link for [1]:
https://osmocom.org/projects/osmopcu/wiki/OsmoPCU#Position-in-a-typical-Osmo...
On 7/30/19 10:23 AM, Oliver Smith wrote:
Hello Harald and Vadim,
On 7/29/19 8:42 PM, Harald Welte wrote:
Thanks also from my side. Given that the amount of resources we have for writing PCU tests is rather limited, I would suggest Oliver to stay with virt_phy for now and focus on the actual PCU tests and not on building required infrastructure.
Sounds good.
But as I'm just diving into this, I'll get the existing but disabled (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests running first. I'll start with virt_phy for now, and then see how far I can get with it.
The tests you mentioned were passing at some point. Of course our TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since, so there may be some fall-out :(
It is great that they were already passing in the past. Harald, do you happen to still have the configs around for running these two tests?
I am trying to piece it together, and so far I have the following. It would be great if you could point out any misconceptions I have.
The raw PCU tests, that are currently running in Jenkins, only start OsmoPCU and the testsuite. When doing the same for TC_ul_tbf and TC_ul_tbf_single_llc_sizes, the testsuite fails to establish the BSSGP connection:
MTC@gsmdevel: Test case TC_ul_tbf finished. Verdict: fail reason: Timeout establishing BSSGP connection
(This is confusing me a bit, isn't the Gp connection between the SGSN and GGSN according to [1]? But I am assuming, that this means the Gb connection towards the PCU.)
Looking at the osmo-pcu log, I find that it won't do anything (not accept connections) until it successfully connects to /tmp/pcu_bts.
I am starting osmo-bts-virtual in order to provide /tmp/pcu_bts. The socket appears, but it will also not properly start up until it connects to something via A-bis OML. So I am also starting osmo-bsc to provide that (I have looked at ttcn3-bts-test, which does it the same way).
Now osmo-bts-virtual is connecting to osmo-bsc, but osmo-bsc is dropping the connection immediately for some reason. Probably a mismatch in the configs, though at least the unit id is matching.
My current understanding is, that the following components need to run:
osmo-pcu | | /tmp/pcu_bts | osmo-bts-virtual ---A-bis OML--- osmo-bsc | | ? | virt_phy | | /tmp/osmocom_l2 | testsuite
Is that accurate? How does the connection between osmo-bts-virtual and virt_phy work?
Thanks, Oliver
-
Harald Welte -
Oliver Smith -
Vadim Yanitskiy