26 Jul
2019
26 Jul
'19
2:23 p.m.
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
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
26 Jul
26 Jul
3:44 p.m.
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#…
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.
29 Jul
29 Jul
10:50 a.m.
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
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
8:42 p.m.
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 :(
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
30 Jul
30 Jul
10:23 a.m.
Hello Harald and Vadim,
On 7/29/19 8:42 PM, Harald Welte wrote:
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:
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 :( 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
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
10:29 a.m.
Forgot to add the link for [1]:
On 7/30/19 10:23 AM, Oliver Smith wrote:
Hello Harald and Vadim,
On 7/29/19 8:42 PM, Harald Welte wrote:
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:
--
- Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
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 :( 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
1755
days inactive
1759
days old
5 comments
3 participants
participants (3)
-
Harald Welte -
Oliver Smith -
Vadim Yanitskiy