30 May
2015
30 May
'15
9:43 p.m.
Otherwise you have to restart BTS or at least break the RSL connection
to apply the change.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
2 Jun
2 Jun
9:26 a.m.
On 30 May 2015, at 21:43, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
Otherwise you have to restart BTS or at least break the RSL connection
to apply the change.
Yes we certainly should apply modifications at runtime but probably not by adding
auto-update to each command. When I change LAC/CI/ms_max_power I don’t want
to update the SI three times.
We really need to have a “commit”/“apply” kind of command that applies OML and
RSL modifications.
holger
15 Jun
15 Jun
9:01 p.m.
On Jun 2, 2015 9:26 AM, "Holger Freyther" <holger(a)freyther.de> wrote:
by adding
> On 30 May 2015, at 21:43, Alexander Chemeris <
alexander.chemeris(a)gmail.com> wrote:
Otherwise you have to restart BTS or at least break the RSL connection
to apply the change.
Yes we certainly should apply modifications at runtime but probably not auto-update to each command. When I change
LAC/CI/ms_max_power I don’t
want
to update the SI three times.
We really need to have a “commit”/“apply” kind of command that applies
OML and
RSL modifications.
I agree that transactional functionality would be nice and I had been
thinking about this. But it's a big change which should be well planned and
requires considerable effort to go through all commands and split
configuration from application. One issue is that we'll need to create
"shadow" registers for the non applied settings. E.g. in case of power
control, the setting was actually applied at the BSC part of the control
(it was using the setting variable directly), but was not propagated to the
BTS party, which was really confusing from a user perspective.
In short - I agree that such feature would be nice, but I don't think this
is a showstopper for this patch, because it just makes things more
consistent.
Btw, control interface also applies the change immediately. Having vty and
control to diverge is quite confusing.
--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
17 Jun
17 Jun
8:04 a.m.
On 15 Jun 2015, at 21:01, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
Good Morning Alexander,
I agree that transactional functionality would be nice
and I had been thinking about this. But it's a big change which should be well planned
and requires considerable effort to go through all commands and split configuration from
application. One issue is that we'll need to create "shadow" registers for
the non applied settings. E.g. in case of power control, the setting was actually applied
at the BSC part of the control (it was using the setting variable directly), but was not
propagated to the BTS party, which was really confusing from a user perspective.
In short - I agree that such feature would be nice, but I don't think this is a
showstopper for this patch, because it just makes things more consistent.
we will not be able to find an agreement here. The current behavior is not consistent (we
have attributes that apply immediately, after a BTS restart or even only after the restart
of
the system). Moving one VTY command from one class to another doesn’t improve the
consistency in any way. The same inconsistency remains in the system, we face the same
issue in documenting the inconsistencies.
So when/how do we want to apply changes? Should all changes be abpplied after an
“apply” command? How is it done by other vendors that offer a VTY like interface?
holger
18 Jun
18 Jun
10:15 a.m.
The current behavior is not consistent (we have
attributes that apply
immediately, after a BTS restart or even only after the restart of the system).
...
So when/how do we want to apply changes? Should all
changes be abpplied
after an “apply” command? How is it done by other vendors that offer a VTY
like interface?
I think it is sometimes tied into the admin lock/unlock functionality. So for example, a
cell maybe 'locked' and the transmitter disabled, at which point parameters can be
changed as required. Then when the cell is unlocked, the new parameter set is then
applied before the transmitter is re-enabled.
For co-dependent parameters there may be a validation step prior to unlock to ensure that
the whole configuration is consistent and valid, though I can't think of many such
parameters in this situation.
An alternative method is to 'lock' a cell by leaving it transmitting but marking
it as barred in the SI.
Such a locking scheme does raise some questions as to the granularity i.e. do we lock at a
BTS, BSC, MSC level or each one. And therefore the vty needs to know which parameters can
be changed according to which network entities are locked - though the command hierarchy
could lend some description to that.
Kind Regards,
Mike
24 Jun
24 Jun
12:27 a.m.
Hi Holger,
On Wed, Jun 17, 2015 at 2:04 AM, Holger Freyther <holger(a)freyther.de> wrote:
Please note that the current behavior of this command is that it
already applies the change immediately by setting bts->ms_max_power.
This value is then used at rsl_rx_chan_rqd() to initialize
lchan->ms_power. But it does not apply it to SIs sent by the same BTS,
which makes the effect of the command inconsistent. The commit I
suggest just makes the behavior of the command consistent.
Please also note that it makes complete sense to apply this value
immediately when you're doing live cell tuning.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
On 15 Jun
2015, at 21:01, Alexander Chemeris <alexander.chemeris(a)gmail.com> wrote:
I agree that transactional functionality would be nice and I had been thinking about
this. But it's a big change which should be well planned and requires considerable
effort to go through all commands and split configuration from application. One issue is
that we'll need to create "shadow" registers for the non applied settings.
E.g. in case of power control, the setting was actually applied at the BSC part of the
control (it was using the setting variable directly), but was not propagated to the BTS
party, which was really confusing from a user perspective.
In short - I agree that such feature would be nice, but I don't think this is a
showstopper for this patch, because it just makes things more consistent.
we will not be able to find an agreement here. The current behavior is not consistent
(we
have attributes that apply immediately, after a BTS restart or even only after the
restart of
the system). Moving one VTY command from one class to another doesn’t improve the
consistency in any way. The same inconsistency remains in the system, we face the same
issue in documenting the inconsistencies.
4:50 p.m.
On 24 Jun 2015, at 00:27, Alexander Chemeris
<alexander.chemeris(a)gmail.com> wrote:
Dear Alexander,
Please note that the current behavior of this command
is that it
already applies the change immediately by setting bts->ms_max_power.
This value is then used at rsl_rx_chan_rqd() to initialize
lchan->ms_power. But it does not apply it to SIs sent by the same BTS,
which makes the effect of the command inconsistent. The commit I
suggest just makes the behavior of the command consistent.
we have completed the circle now and I don’t want to run another round. The
ms_max_power aspect is annoying but it shows that we need to progress and
look at the bigger picture. Are you willing to do that?
holger
11:45 p.m.
Hi Holger,
On Wed, Jun 24, 2015 at 10:50 AM, Holger Freyther <holger(a)freyther.de> wrote:
In the spirit of scratching the itch, I do need the ms_max_power
patch, as it fixes an obvious issue and I want to share it with the
community. I'm fine maintaining it шт a branch if it's not good enough
for the master.
OTOH I don't have an itch with the lack of “commit”/“apply”
functionality, so it's hard for me to discuss it - I don't know
requirements and use cases. I see a theoretical value of it, but
relying on theoretical values is a sure way to over-engineer in my
experience. If you have a real need for it, then you're probably much
more qualified to look at it.
I hope that's fair enough.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves, Inc.
https://fairwaves.co
On 24 Jun
2015, at 00:27, Alexander Chemeris <alexander.chemeris(a)gmail.com> wrote:
Please note that the current behavior of this command is that it
already applies the change immediately by setting bts->ms_max_power.
This value is then used at rsl_rx_chan_rqd() to initialize
lchan->ms_power. But it does not apply it to SIs sent by the same BTS,
which makes the effect of the command inconsistent. The commit I
suggest just makes the behavior of the command consistent.
we have completed the circle now and I don’t want to run another round. The
ms_max_power aspect is annoying but it shows that we need to progress and
look at the bigger picture. Are you willing to do that?
3240
days inactive
3265
days old
7 comments
3 participants
participants (3)
-
Alexander Chemeris -
Holger Freyther -
Mike McTernan (wavemobile)