23 May
2019
23 May
'19
1:15 p.m.
Hi Vadim,
I'm currently facing the problem of testing hand-over related channel-activation
in OsmoBTS. Three are various rules about how this has to be done, and a closer
look indicates that both osmo-bts-trx as well as osmo-bts-sysmo don't get that
right at all.
I'd like to write TTCN-3 tests as part of BTS_Tests.ttcn, which uses L1CTL
to control a (virtual or real) L1 for the MS side of testing the BTS.
To break this down to low-level requirements in terms of MS capabilities:
* switch to a different ARFCN
* switch to a speciifed timeslot
* change the synchroniztaion (in terms of where we currently are in the TDMA
multiplex) to a given neighbor cell. The MS will have performed neighbor
measurements before, and as part of that will hav received FCCH + SCH and
hence know the timing both in terms of carrier freq as well as TDMA position
[none of this is relevant for a fake_trx + trxcon setup]
* ability to enable only the receiver for the main channel (SDCCH/FACCH), but
suppress any reception (or passing up of received) SACCH.
* ability to transmit RACH burst[s] in uplink on that new dedicated channel
* ability to later on enable full Rx/Tx of all logical channels on that dedicated
channel
I've looked at the jolly/handover branch from 2013, and rebased that on top of
current
master, the result can be seen in laforge/jolly_handover_rebase
Change-Id Iadbc47f006d1f8a019822aedee180814de13cb2d specifically adds new flags
to DM_EST_REQ to
* disable uplink transmission
* use the sync information of a neighbor cell
I would like to get at least that change to L1CTL merged to master, and while
doing that, update all implementations of L1CTL at the same time. It may make
sense to also merge Change-Id I792b52d9bf115a2def9720eed3d62982d8cdbe00 while
at it, which is required for neighbor channel measurements + reporting.
We should also use that opportunity to introduce some kind of versioning support
to L1CTL, to ensure future extensions of the protocol can be made in a way where
incompatibility can at least be detected at runtime.
Now the next question is how to this will impact trxcon/fake_trx. AFAICT,
there is a comment in trxcon hinting that the TRX TUNE comamnd of a DM_EST_REQ
would fail if there was already and established channel before. Is that correct?
If so, what is the suggested/recommended way to get trxcon to support at least
the minimum of what's required for handover in a virtual environment?
Regards,
Harald
--
- 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)
26 May
26 May
1:50 a.m.
Hi Harald,
sorry for late response, I took me some time to recover after PHDays.
I'd like to write TTCN-3 tests as part of
BTS_Tests.ttcn,
which uses L1CTL to control a (virtual or real) L1 for
the MS side of testing the BTS.
Great! I will be happy to cooperate you on the MS side.
To break this down to low-level requirements
in terms of MS capabilities:
* switch to a different ARFCN
* switch to a speciifed timeslot
As far as I understand (sorry, my HO knowledge is very limited),
this should be possible while being on a dedicated channel. In
general, it is already possible with the current code: that's
exactly how ASSIGNMENT COMMAND works AFAIR.
To do that, the controlling side need to send a L1CTL_RESET_REQ,
followed by L1CTL_FBSB_REQ, and then finally L1CTL_DM_EST_REQ.
Otherwise the old dedicated connection would remain active...
The main problem of this approach is that the new ARFCN the MS
is requested to switch needs to be C0 (i.e. transmit both FCCH
and BCCH). Otherwise L1CTL_FBSB_REQ would fail.
That's a poor man's (I would even say ugly) approach, and as it
turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule
frequency change at the given TDMA frame number! But not the
timeslot change :/
At the moment, trxcon does not support L1CTL_DM_FREQ_REQ. But I
think this is the way to go. (Ab)using L1CTL_DM_EST_REQ in order
to change ARFCN and/or TDMA TN looks like a bad idea to me. It
should be used for a single purpose - go from IDLE to DEDICATED.
* change the synchroniztaion (in terms of where we
currently are
in the TDMA multiplex) to a given neighbor cell. [...]
[none of this is relevant for a fake_trx + trxcon setup]
Why not relevant? I believe with the recently refactored FakeTRX
we can connect as much BTS and/or TRX instances as we need, and
I think we can even play with the clock distribution, so two or
more BTS instances would use independent clock sources ;)
For changing TDMA parameters, we can think about introducing a new
message, e.g. L1CTL_DM_TDMA_REQ, that by analogy with the mentioned
L1CTL_DM_FREQ_REQ would allow to schedule TDMA parameters change
at the given TDMA frame number.
* ability to enable only the receiver for the main
channel
(SDCCH/FACCH), but suppress any reception (or passing up
of received) SACCH.
So this is only needed for handover, right? If yes, we can extend
the 'l1ctl_info_ul' (which is included in L1CTL_DM_FREQ_REQ) with
such information. Fortunately, there are two padding bytes in it.
* ability to transmit RACH burst[s] in uplink on that
new dedicated channel
So there is no warranty that the new dedicated channel would contain
RACH slots, right? That's another limitation of trxcon: it can send
RACH bursts on RACH slots only, and only on TS0.
The second limitation can be easily fixed by indicating a proper
timeslot in the 'l1ctl_info_ul' header of L1CTL_RACH_REQ. Currently
the higher layers leave this header empty, so we always assume
'chan_nr' == 0x88, which corresponds to RACH on TS0.
The first limitation comes from the architecture of trxcon. Unlike
the firmware for Calypso targets, trxcon's scheduler is 'layout-based',
i.e. we have the TDMA multiframe layouts and mapping the current TDMA
frame number to them gives us an idea what to do.
The firmware's scheduler, which runs on top of the DSP's internal
scheduler, is following the 'task-based' approach, i.e. we have
different sets of active and inactive tasks with TDMA frame
numbers indicating when exactly we should execute them.
The 'layout-based' approach does not allow us to schedule any tasks,
such as frequency redefinition, TDMA parameters change, or Access
Burst transmission, on a given frame number. Therefore, we either
need to completely switch (i.e. rewrite) trxcon to the 'task-based'
architecture, or extent the existing scheduler with the ability to
schedule some tasks, so we would have a mixed architecture.
* ability to later on enable full Rx/Tx of all logical
channels
on that dedicated channel
It looks like we need a new L1CTL message for (de)activating TDMA
timeslots on the current channel, and (de)activate particular
logical channels on them. That would be also useful for other
tests, e.g. multi-TS transmission in (E)GPRS.
I've looked at the jolly/handover branch from
2013, and rebased
that on top of current master, the result can be seen in
laforge/jolly_handover_rebase
I had a quick look so far, and in general it looks good to me.
We just need to conclude on the L1CTL changes (see above).
We should also use that opportunity to introduce some
kind of
versioning support to L1CTL, to ensure future extensions of the
protocol can be made in a way where incompatibility can at least
be detected at runtime [...]
A very early / draft implementation can be found
in a separate branch 'fixeria/l1ctl_nego':
https://git.osmocom.org/osmocom-bb/log/?h=fixeria/l1ctl_nego
this branch actually depends on:
https://gerrit.osmocom.org/#/c/libosmocore/+/10034/
I wish I had more time to finish it...
Now the next question is how to this will impact
trxcon/fake_trx.
AFAICT, there is a comment in trxcon hinting that the TRX TUNE
comamnd of a DM_EST_REQ would fail if there was already an
established channel before. Is that correct?
I just checked the code, and I think it would not fail, but
result into having the old channel left active. As I already
mentioned above, I don't like the idea of abusing this message
for handover.
If so, what is the suggested/recommended way to get
trxcon to
support at least the minimum of what's required for handover
in a virtual environment?
Let's resume everything, so that would be the answer:
- We should not abuse L1CTL_DM_FREQ_REQ for handover, it should
be used for a single purpose: switch from IDLE to DEDICATED.
- Let's instead use both L1CTL_DM_FREQ_REQ and L1CTL_DM_TDMA_REQ
(to be introduced) for handover remated manipulations.
- Alternatively, we can introduce L1CTL_DM_HANDOVER_REQ that
would contain both FDMA and TDMA parameters.
- Let's introduce a new L1CTL message for (de)activating TDMA
timeslots on the current channel, and (de)activating its
logical channels.
- We need to implement the ability to schedule tasks at the given
TDMA frame number in trxcon, so it would be possible to change
the FDMA and TDMA parameters, and send Access Bursts
on non-RACH slots.
- Let's try to hack the clock distribution in FakeTRX, so that
would allow us to test handover between non-synchronized
virtual Base Stations.
Please note that I don't insist on any of these points, this is just
my understanding of the way how the handover integration should be
done. I am open for discussion ;)
With best regards,
Vadim Yanitskiy.
29 May
29 May
12:01 a.m.
Hi Vadim,
On Sun, May 26, 2019 at 06:50:21AM +0700, Vadim Yanitskiy wrote:
correct. However, for BTS_Tests.ttcn it doesn't really matter, as
we are testing the individual low-level transactions and we can
simply
* RSL CHAN ACT (type == handover)
* ask the MS to enter dedicated mode directly on that timeslot
without any actual hand-over and no previous channel present. But
that of course is insufficient for using it on real networks.
you are right for the frame numbers which of course would be different
between [even virtual] BTSs. However, there's of course no acquisition
of FCCH to track the carrier frequency, which is probably what I was
thinking, but not writing about.
The new dedicated channel is a normal SDCCH or TCH/F or TCH/H and
there are no "rach slots".
I would like to think of it as "Layer 1 SAPIs", which could be activated
and deactivated on the given dedicated channel. We have the same
concept in osmo-bts-{sysmo,lc15,oc2g}, where one can e.g. activate
SDCCH independent of SACCH, and do that independently for UL and DL.
So I would completely decouple the different domains of:
1) changing the 'sync' (clock + TDMA) to a cell
This can either be achieved by
a) the classic FBSB_REQ during cell search / cell selection, or
b) with a some new primitive which allows us to switch to one of the
neighbors (whose clock + TDMA sync has to be established during the
idle slots in dedicated mode). In Jolly's work, this is done
with a special parameter to DM_EST_REQ, but I would make that
a separate primitive.
2) changing the frequency while retaining sync
This is used whenever channels on different ARFCN (or HSN/MAIO)
on the same BTS are assigned to the MS. Changing frequency *without*
also changing the timeslot (like our existing DM_FREQ_REQ) only
happens in case of frequency changes/redefinitions, which I would
consider rather rare and unusual events during normal operation.
But yes, best to leave the DM_FREQ_REQ for this purpose unmodified.
3) establishing dedicated mode (DM_EST_REQ). It currently automatically
activates all L1 SAPSs, but see below for my idea there.
4) returning back to idle mode (DM_REL_REQ). Care has to be taken about the
situation where we fist hand-over to a new cell in dedicated mode,
and then switch back to idle mode *on the new cell with its
clock/tdma*.
4) activating/deactivating L1 SAPIs within that logical channel.
this is where we can e.g. activate SACCH or not - or even activate
RACH or not on a dedicated channel. The bit-masks of initial L1
sapis for UL and DL could be part of L1CTL_DM_EST_REQ. We could then
modify that later using a L1CTL_DM_MOD_REQ (modify request)?
So a typical hand-over scenario would then be
FBSB_REQ - establish sync to first cell
RACH_REQ
DM_EST_REQ - establishing initial channel
<MS performs neighbor mesurements in idle frames>
<MS performs measurement reporting of neighbors in UL SACCH>
<bsc sends handover command>
DM_REL_REQ - release old channel
SYNC_NEIGH_REQ - change clock + tdma sync to a specific neighbor cell
DM_EST_REQ - establish new channel on that neighbor cell;
* ARFCN can be different from C0 of that cell!
* initial L1 SAPI bitmask contains only DL DCCH + FACCH
RACH_REQ
<BTS sends us PHYSICAL INFO in DL>
DM_MOD_REQ - activate UL DCCH + ACCH
ACK.
I know the feeling...
I guess you're referring to DM_EST_REQ here? See above.
Great! I will be happy to cooperate you on the MS
side.
thanks!
To break this
down to low-level requirements
in terms of MS capabilities:
* switch to a different ARFCN
* switch to a speciifed timeslot
As far as I understand (sorry, my HO knowledge is very limited),
this should be possible while being on a dedicated channel. In general, it is already possible with the current
code: that's
exactly how ASSIGNMENT COMMAND works AFAIR.
good.
To do that, the controlling side need to send a
L1CTL_RESET_REQ,
followed by L1CTL_FBSB_REQ, and then finally L1CTL_DM_EST_REQ.
Otherwise the old dedicated connection would remain active...
Sounds like we need a DM_REL_REQ - and we actually have one. I would
normally expect that to be used to release dedicated mode?
Looking at layer23, it seems we have DM_REL_REQ, then RESET, then
a new DM_EST_REQ during assignment.
The main problem of this approach is that the new
ARFCN the MS
is requested to switch needs to be C0 (i.e. transmit both FCCH
and BCCH). Otherwise L1CTL_FBSB_REQ would fail.
You are referring to trxcon or calypso-layer1 here?
I'm asking as it is a perfectly natural occurring event to have an
ASSIGNMENT on the same BTS but to a dedicated channel on a different
ARFCN - and I would be surprised if caylypso-l1 of osmocom-bb wouldn't
support that.
That's a poor man's (I would even say ugly)
approach, and as it
turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule
frequency change at the given TDMA frame number! But not the
timeslot change :/
I actually think it's not ugly at all. You release the old dedicated
channel and establish a new one.
At the moment, trxcon does not support
L1CTL_DM_FREQ_REQ. But I
think this is the way to go.
This is for changing the frequency on an exstablished dedicated channel,
because the network descides to change its ARFCNs or hopping sequences
at some point during operation. A very rare event, which I wouldn't
be too worried about if we didn't cover it (but we in fact do in
OsmocomBB!).
(Ab)using L1CTL_DM_EST_REQ in order to change ARFCN
and/or TDMA TN
looks like a bad idea to me. It should be used for a single purpose -
go from IDLE to DEDICATED.
It's not abusing. We actually do release the old channel and establish
a new one...
* change the
synchroniztaion (in terms of where we currently are
in the TDMA multiplex) to a given neighbor cell. [...]
[none of this is relevant for a fake_trx + trxcon setup]
Why not relevant? I believe with the recently refactored FakeTRX
we can connect as much BTS and/or TRX instances as we need, and
I think we can even play with the clock distribution, so two or
more BTS instances would use independent clock sources ;) For changing TDMA parameters, we can think about
introducing a new
message, e.g. L1CTL_DM_TDMA_REQ, that by analogy with the mentioned
L1CTL_DM_FREQ_REQ would allow to schedule TDMA parameters change
at the given TDMA frame number.
I don't like such hacks, sorry.
* ability to enable only the receiver for the
main channel
(SDCCH/FACCH), but suppress any reception (or passing up
of received) SACCH.
So this is only needed for handover, right? If yes, we can extend
the 'l1ctl_info_ul' (which is included in L1CTL_DM_FREQ_REQ) with
such information. Fortunately, there are two padding bytes in it. * ability to
transmit RACH burst[s] in uplink on that
new dedicated channel
So there is no warranty that the new dedicated channel would contain
RACH slots, right? That's another limitation of trxcon: it can send
RACH bursts on RACH slots only, and only on TS0. The second limitation can be easily fixed by
indicating a proper
timeslot in the 'l1ctl_info_ul' header of L1CTL_RACH_REQ. Currently
the higher layers leave this header empty, so we always assume
'chan_nr' == 0x88, which corresponds to RACH on TS0.
ACK.
The 'layout-based' approach does not allow us
to schedule any tasks,
such as frequency redefinition, TDMA parameters change, or Access
Burst transmission, on a given frame number. Therefore, we either
need to completely switch (i.e. rewrite) trxcon to the 'task-based'
architecture, or extent the existing scheduler with the ability to
schedule some tasks, so we would have a mixed architecture.
I think a complete rewrite might be too much work.
* ability to
later on enable full Rx/Tx of all logical channels
on that dedicated channel
It looks like we need a new L1CTL message for (de)activating TDMA
timeslots on the current channel, and (de)activate particular
logical channels on them. That would be also useful for other
tests, e.g. multi-TS transmission in (E)GPRS. I've
looked at the jolly/handover branch from 2013, and rebased
that on top of current master, the result can be seen in
laforge/jolly_handover_rebase
I had a quick look so far, and in general it looks good to me.
We just need to conclude on the L1CTL changes (see above). We should also use that opportunity to introduce
some kind of
versioning support to L1CTL, to ensure future extensions of the
protocol can be made in a way where incompatibility can at least
be detected at runtime [...]
A very early / draft implementation can be found
in a separate branch 'fixeria/l1ctl_nego':
https://git.osmocom.org/osmocom-bb/log/?h=fixeria/l1ctl_nego
this branch actually depends on:
https://gerrit.osmocom.org/#/c/libosmocore/+/10034/
I wish I had more time to finish it... If so, what is
the suggested/recommended way to get trxcon to
support at least the minimum of what's required for handover
in a virtual environment?
Let's resume everything, so that would be the answer:
- We should not abuse L1CTL_DM_FREQ_REQ for handover, it should
be used for a single purpose: switch from IDLE to DEDICATED. - Let's instead use both L1CTL_DM_FREQ_REQ and
L1CTL_DM_TDMA_REQ
(to be introduced) for handover remated manipulations.
I would argue L1CTL_DM_FREQ_REQ is for frequency changes while on
an active dedicated channel on a given BTS.
For hand-over, it's actually almost like we're establishing a completely
new dedicated L1 channel. The higher-layer state (L3+) is retained,
but L1 and L2 are completely new. So I don't think this is just
a frequency + TDMA change.
- Alternatively, we can introduce
L1CTL_DM_HANDOVER_REQ that
would contain both FDMA and TDMA parameters.
I would think that's too specific. I would say we release the old
channel and establish a new one. And if the new one fails to establish,
we re-establish the old one using the freq + TDMA sync information we've
kept around for the old cell.
- Let's introduce a new L1CTL message for
(de)activating TDMA
timeslots on the current channel,
I would consider this part of DM_EST_REQ + DM_REL_REQ - for both
the Assignment and the Handover case. The only difference is whether
we stay with freq+TDMA sync on the current cell, or on a new cell.
and (de)activating its logical channels.
bitmask of L1 SAPI in DM_EST_REQ and new DM_MOD_REQ.
- We need to implement the ability to schedule tasks
at the given
TDMA frame number in trxcon, so it would be possible to change
the FDMA and TDMA parameters, and send Access Bursts
on non-RACH slots.
Not sure how much of that we really need beyond ability to send RACH
on normal traffic channels...
Regards,
Harald
--
- 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 May
30 May
10:38 a.m.
New subject: L1CTL extension (was Re: hand-over in L1CTL / trxcon)
Hi Vadim and others,
given how long L1CTL has been around, and how many programs implement
it by now, I really would like to ensure backwards compatibility without
introducing weird breakage all over the place.
The good news: I think it's possible to extend L1CTL in a
backwards-compatible way, and I started with a related implementation.
Some of my raw notes below:
---
Extension of L1CTL in a compatible way
* enhance l1ctl_reset with version and feature bitmap
** used by L1CTL_RESET_CONF, possibly also REQ, IND
** old implementation ignores trailer
** new implementation recognizes new format due to longer message (and enables use of new
features)
* new DM_EST_2_REQ
** sent by L23 only if feature-bit was set in RSEET_CONF
** contains additional fields
*** L1 SAPI bitmask
*** sync_source member to select own cell or neighbor cell sync info
* new DM_EST_2_CONF
** response to _REQ (which is currently missing from DM_EST_REQ)
* extend l1ctl_neigh_pm_ind with new fields at end
** L23 can use size to determine if new fields exist or not
* new DM_MODIFY_REQ
** sent by L23 to change L1 SAPI bitmask
* new DM_MODIFY_CONF to confirm it
/* bit definitions for individual features communicated in RESET_CONF */
enum l1ctl_feature {
L1CTL_FT_DM_EST2_MODIFY, /* DM_EST_2 and DM_MODIFY procedures */
L1CTL_FT_RACH_DM, /* RACH can be sent in dedicated mode */
L1CTL_FT_EXT_RACH_REQ, /* Extended RACH (11bit) support */
L1CTL_FT_SPKR_MIC, /* Hardware Speaker + Microphone supported */
L1CTL_FT_TRAFFIC_IND,
L1CTL_FT_BURST_IND,
L1CTL_FT_TBF, /* support for TBF_CFG and DATA_TBF procedures */
L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */
L1CTL_FT_SIM_SLOT, /* physical SIM slot exists */
L1CTL_FT_BAND_850,
L1CTL_FT_BAND_900,
L1CTL_FT_BAND_1800,
L1CTL_FT_BAND_1900,
L1CTL_FT_CIPH_A51,
L1CTL_FT_CIPH_A52,
L1CTL_FT_CIPH_A53,
};
---
I won't go "full steam ahead" on this, but will try to get it
implemented within the next week or so.
Regards,
Harald
--
- 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)
31 May
31 May
4:55 p.m.
Hi Harald,
Nevermind. This is a result of my delusion. See above.
Sounds like we need a DM_REL_REQ - and we actually
have one. I would
normally expect that to be used to release dedicated mode?
Oh, right! L1CTL_DM_REL_REQ magically slipped my mind. Of course,
this one is used to release dedicated mode, and trxcon does
support it already. Sorry for confusion.
The main
problem of this approach is that the new ARFCN the MS
is requested to switch needs to be C0 (i.e. transmit both FCCH
and BCCH). Otherwise L1CTL_FBSB_REQ would fail.
You are referring to trxcon or calypso-layer1 here? [...]
That's a poor man's (I would even say
ugly) approach, and as it
turns out, there is L1CTL_DM_FREQ_REQ, which allows to schedule
frequency change at the given TDMA frame number! But not the
timeslot change :/
I actually think it's not ugly at all. You release the old
dedicated channel and establish a new one. Looking at layer23, it seems we have DM_REL_REQ, then
RESET,
then a new DM_EST_REQ during assignment.
Right. I am now wondering, wouldn't this intermediate
L1CTL_RESET_REQ cause an additional delay for handover?
> So there is no warranty that the new dedicated
channel would contain
> RACH slots, right? That's another limitation of trxcon: it can send
> RACH bursts on RACH slots only, and only on TS0.
Fortunately, I found a work around, please see:
https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/
I've just confirmed that trxcon properly sends Access Bursts
on any (activated by L1CTL_DM_EST_REQ) time-slot, please see:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/
... and of course discovered a problem of OsmoBTS ;)
In short, it doesn't detect handover RACH.
The problem seems to be here:
https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n986
An Access Burst is merely ignored if a logical channel is not active.
King regards,
Vadim Yanitskiy.
4 Jun
4 Jun
6:31 p.m.
Hi Vadim,
On Fri, May 31, 2019 at 09:55:22PM +0700, Vadim Yanitskiy wrote:
I would assume the reset of the data structures is quite fast compared
to anything on the GSM radio interface? Not sure if it would matter?
Thanks, this has meanwhile ben merged.
Looking at
layer23, it seems we have DM_REL_REQ, then RESET,
then a new DM_EST_REQ during assignment.
Right. I am now wondering, wouldn't this intermediate
L1CTL_RESET_REQ cause an additional delay for handover? > So there
is no warranty that the new dedicated channel would contain
> RACH slots, right? That's another limitation of trxcon: it can send
> RACH bursts on RACH slots only, and only on TS0.
Fortunately, I found a work around, please see:
https://gerrit.osmocom.org/#/c/osmocom-bb/+/14274/ I've just confirmed that trxcon properly sends
Access Bursts
on any (activated by L1CTL_DM_EST_REQ) time-slot, please see:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14291/
Which has also been merged, and is executing + passing for seveal
consecutive days, see
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_resu…
Thanks!
In short, it doesn't detect handover RACH.
The problem seems to be here:
https://git.osmocom.org/osmo-bts/tree/src/common/scheduler.c#n986
An Access Burst is merely ignored if a logical channel is not active.
The logical channel must be previously activated by the BSC using RSL
CHAn ACT with type == handover.
Regards,
Harald
--
- 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)
1794
days inactive
1806
days old
baseband-devel@lists.osmocom.org
5 comments
2 participants
participants (2)
-
Harald Welte -
Vadim Yanitskiy