resurrect meas_feed.c: vty, vty-test
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
2018-04-20 13:53:53 +00:00
|
|
|
OsmoBSC> enable
|
|
|
|
|
2021-06-08 22:50:43 +00:00
|
|
|
OsmoBSC# list
|
|
|
|
...
|
|
|
|
bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> modify (vamos|non-vamos) [tsc] [<1-4>] [<0-7>]
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 ?
|
2021-04-25 15:02:15 +00:00
|
|
|
activate Manual Channel Activation (e.g. for BER test)
|
|
|
|
activate-vamos Manual Channel Activation, in VAMOS mode
|
|
|
|
deactivate Manual Channel Deactivation (e.g. for BER test)
|
|
|
|
modify Manually send Channel Mode Modify (for debugging)
|
|
|
|
mdcx Modify RTP Connection
|
2021-05-19 00:48:40 +00:00
|
|
|
reassign-to Trigger Assignment to an unused lchan on the same cell
|
2021-04-25 15:02:15 +00:00
|
|
|
handover Manually trigger handover (for debugging)
|
|
|
|
assignment Manually trigger assignment (for debugging)
|
2021-06-08 22:50:43 +00:00
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 modify ?
|
|
|
|
vamos Enable VAMOS channel mode
|
|
|
|
non-vamos Disable VAMOS channel mode
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 modify vamos ?
|
|
|
|
[tsc] Provide specific TSC Set and Training Sequence Code
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 modify vamos tsc ?
|
|
|
|
[<1-4>] TSC Set
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 modify vamos tsc 1 ?
|
|
|
|
[<0-7>] Training Sequence Code
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 modify vamos tsc 1 0 ?
|
|
|
|
<cr>
|
|
|
|
|
2021-05-24 00:09:22 +00:00
|
|
|
|
|
|
|
OsmoBSC# list
|
|
|
|
...
|
2021-05-23 14:58:11 +00:00
|
|
|
bts <0-255> trx <0-255> timeslot <0-7> (sub-slot|vamos-sub-slot) <0-7> (activate|activate-vamos|deactivate) (hr|fr|efr|amr|sig) [<0-7>]
|
2021-05-24 00:09:22 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC# bts?
|
|
|
|
bts BTS Specific Commands
|
|
|
|
|
|
|
|
OsmoBSC# bts ?
|
|
|
|
<0-255> BTS Number
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 ?
|
|
|
|
resend-system-information Re-generate + re-send BCCH SYSTEM INFORMATION
|
|
|
|
resend-power-control-defaults Re-generate + re-send default MS/BS Power control parameters
|
power_control: implement BCCH carrier power reduction operation
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
2021-06-21 19:55:46 +00:00
|
|
|
c0-power-reduction BCCH carrier power reduction operation
|
2021-05-24 00:09:22 +00:00
|
|
|
trx TRX for manual command
|
|
|
|
oml Manipulate the OML managed objects
|
|
|
|
om2000 Manipulate the OM2000 managed objects
|
|
|
|
|
power_control: implement BCCH carrier power reduction operation
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, starting from version 13.0.0 (2015-11) there is a feature
called 'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
Introduce a VTY command to turn on and off the BCCH carrier power
reduction operation. Also introduce a CTRL command. On the
A-bis/RSL, abuse the BS POWER CONTROL message by setting
the Channel Number IE to 0x80 (RSL_CHAN_BCCH).
Currently, only osmo-bts-trx is supported. A value greater than
zero makes it reduce the power on *inactive* timeslots of the
BCCH carrier. Sending zero disables the BCCH power reduction
mode completely.
For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926.
Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783
Related: SYS#4919
2021-06-21 19:55:46 +00:00
|
|
|
OsmoBSC# bts 0 c0-power-reduction ?
|
|
|
|
<0-6> Power reduction value (in dB, even numbers only)
|
|
|
|
|
2021-05-24 00:09:22 +00:00
|
|
|
OsmoBSC# bts 0 trx ?
|
|
|
|
<0-255> TRX Number
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 ?
|
|
|
|
timeslot Timeslot for manual command
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot ?
|
|
|
|
<0-7> Timeslot Number
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 ?
|
2021-05-23 14:58:11 +00:00
|
|
|
pdch Packet Data Channel
|
|
|
|
sub-slot Primary sub-slot
|
|
|
|
vamos-sub-slot VAMOS secondary shadow subslot, range <0-1>, only valid for TCH type timeslots
|
2021-05-24 00:09:22 +00:00
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot ?
|
|
|
|
<0-7> Sub-slot Number
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 ?
|
2021-04-25 15:02:15 +00:00
|
|
|
activate Manual Channel Activation (e.g. for BER test)
|
|
|
|
activate-vamos Manual Channel Activation, in VAMOS mode
|
|
|
|
deactivate Manual Channel Deactivation (e.g. for BER test)
|
|
|
|
modify Manually send Channel Mode Modify (for debugging)
|
|
|
|
mdcx Modify RTP Connection
|
2021-05-19 00:48:40 +00:00
|
|
|
reassign-to Trigger Assignment to an unused lchan on the same cell
|
2021-04-25 15:02:15 +00:00
|
|
|
handover Manually trigger handover (for debugging)
|
|
|
|
assignment Manually trigger assignment (for debugging)
|
2021-05-24 00:09:22 +00:00
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate ?
|
|
|
|
hr Half-Rate v1
|
|
|
|
fr Full-Rate
|
|
|
|
efr Enhanced Full Rate
|
|
|
|
amr Adaptive Multi-Rate
|
|
|
|
sig Signalling
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr ?
|
|
|
|
[<0-7>] AMR Mode
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 activate fr 0 ?
|
|
|
|
<cr>
|
|
|
|
|
2021-05-19 00:48:40 +00:00
|
|
|
OsmoBSC# list
|
|
|
|
...
|
|
|
|
bts <0-255> trx <0-255> timeslot <0-7> (sub-slot|vamos-sub-slot) <0-7> reassign-to trx <0-255> timeslot <0-7> (sub-slot|vamos-sub-slot) <0-7> [tsc] [<1-4>] [<0-7>]
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to ?
|
|
|
|
trx Target TRX
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx ?
|
|
|
|
<0-255> TRX nr
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 ?
|
|
|
|
timeslot Target timeslot
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot ?
|
|
|
|
<0-7> timeslot nr
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 ?
|
|
|
|
sub-slot Primary sub-slot
|
|
|
|
vamos-sub-slot VAMOS secondary shadow subslot, range <0-1>, only valid for TCH type timeslots
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 vamos-sub-slot ?
|
|
|
|
<0-7> Sub-slot Number
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 vamos-sub-slot 0 ?
|
|
|
|
[tsc] Provide specific TSC Set and Training Sequence Code
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 vamos-sub-slot 0 tsc ?
|
|
|
|
[<1-4>] TSC Set
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 vamos-sub-slot 0 tsc 1 ?
|
|
|
|
[<0-7>] Training Sequence Code
|
|
|
|
|
|
|
|
OsmoBSC# bts 0 trx 0 timeslot 0 sub-slot 0 reassign-to trx 0 timeslot 0 vamos-sub-slot 0 tsc 1 0 ?
|
|
|
|
<cr>
|
|
|
|
|
resurrect meas_feed.c: vty, vty-test
At this point, meas-feed is usable again, however, osmo-bsc is not able to
include the IMSI in every report like osmo-nitb did.
In consequence, the meas-vis and meas-web tools are unable to handle the
current measurement reports: these so far use the IMSI to list reports, and all
reports without an IMSI are collapsed onto the same line, swapping values.
So though osmo-bsc now sends usable measurement reports via meas-feed, two
avenues to improve should be pursued:
OS#3192: the visualization tools should use bts,ts,ss numbers, not IMSI.
OS#2969: osmo-bsc should always know a mobile identity.
Related: OS#2968
Change-Id: I186c7a995dd2b81746c32a58b55da64ed195a1ce
2018-04-20 13:53:53 +00:00
|
|
|
OsmoBSC# configure terminal
|
|
|
|
OsmoBSC(config)# network
|
|
|
|
OsmoBSC(config-net)# list
|
|
|
|
...
|
|
|
|
meas-feed destination ADDR <0-65535>
|
|
|
|
meas-feed scenario NAME
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC(config-net)# meas-feed destination 127.0.0.23 4223
|
|
|
|
OsmoBSC(config-net)# meas-feed scenario foo23
|
|
|
|
OsmoBSC(config-net)# show running-config
|
|
|
|
...
|
|
|
|
network
|
|
|
|
...
|
|
|
|
meas-feed destination 127.0.0.23 4223
|
|
|
|
meas-feed scenario foo23
|
|
|
|
...
|
2021-07-08 15:46:40 +00:00
|
|
|
|
|
|
|
|
|
|
|
OsmoBSC(config-net)# bts 0
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# list
|
|
|
|
...
|
|
|
|
channel allocator avoid-interference (0|1)
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel?
|
|
|
|
channel Channel Allocator
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel ?
|
|
|
|
allocator Channel Allocator
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator ?
|
Introduce VTY option to forbid use of TCH for non-voicecall signalling
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
2021-07-22 11:25:05 +00:00
|
|
|
ascending Allocate Timeslots and Transceivers in ascending order
|
|
|
|
descending Allocate Timeslots and Transceivers in descending order
|
|
|
|
avoid-interference Configure whether reported interference levels from RES IND are used in channel allocation
|
|
|
|
allow-tch-for-signalling Configure whether TCH/H or TCH/F channels can be used to serve non-call-related signalling if SDCCHs are exhausted
|
2021-07-08 15:46:40 +00:00
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator avoid-interference ?
|
|
|
|
0 Ignore interference levels (default). Always assign lchans in a deterministic order.
|
|
|
|
1 In channel allocation, prefer lchans with less interference.
|
|
|
|
|
Introduce VTY option to forbid use of TCH for non-voicecall signalling
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
2021-07-22 11:25:05 +00:00
|
|
|
OsmoBSC(config-net-bts)# channel allocator allow-tch-for-signalling ?
|
|
|
|
0 Forbid use of TCH for non-call-related signalling purposes
|
|
|
|
1 Allow use of TCH for non-call-related signalling purposes (default)
|
|
|
|
|
2021-07-08 15:46:40 +00:00
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
... !channel allocator avoid-interference
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator avoid-interference 1
|
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
...
|
|
|
|
bts 0
|
|
|
|
...
|
|
|
|
channel allocator avoid-interference 1
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator avoid-interference 0
|
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
... !channel allocator avoid-interference
|
Introduce VTY option to forbid use of TCH for non-voicecall signalling
Usual allocation mechansim, when some signalling channel is needed,
first tries to reserve an SDCCH, and if all of them are exhausted, then
attempts to reserve a TCH as a last resort.
This, however, may cause TCH starvation under certain situations, for
instance if there high load on other services (LU, SMS, etc.).
Hence, it may be desirable for the operator to forbid reservation
of TCH slots once SDCCH become exhausted. This commit is thus adding a
VTY command which allows forbidding it. The default behavior (allow using
TCH timeslots when SDCCHs are exhausted) is kept as before.
The above mentioned prohibition is applied only to non-voicecall related
signalling services. That's because voicecall services will end up
requiring a TCH anyway, and forbidding reservation of TCH straighaway
when SDCCHs are exhausted would mean no voice calls could be initiated
while still TCHs would be available.
Related: SYS#5548
Change-Id: Ib08027125145df26602069bfb51847063b0ccc0c
2021-07-22 11:25:05 +00:00
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
... !channel allocator allow-tch-for-signalling
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator allow-tch-for-signalling 0
|
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
...
|
|
|
|
bts 0
|
|
|
|
...
|
|
|
|
channel allocator allow-tch-for-signalling 0
|
|
|
|
...
|
|
|
|
|
|
|
|
OsmoBSC(config-net-bts)# channel allocator allow-tch-for-signalling 1
|
|
|
|
OsmoBSC(config-net-bts)# show running-config
|
|
|
|
... !channel allocator allow-tch-for-signalling
|