cellular-infrastructure
/
osmo-pcu
mirror of https://gerrit.osmocom.org/osmo-pcu
9
0
Fork 1
Code Issues Releases Wiki Activity
osmo-pcu/src/pcu_vty.c

1317 lines
40 KiB
C
Raw Normal View History

VTY implementation
2012-07-12 12:31:57 +00:00
/* OsmoBTS VTY interface */
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
#include <stdint.h>
misc: Add missing include for atoi pcu_vty.c:128:21: warning: implicit declaration of function 'atoi' is invalid in C99 [-Wimplicit-function-declaration] bts->fc_interval = atoi(argv[0]); ^
2014-07-02 12:56:36 +00:00
#include <stdlib.h>
Fix dozens of compiler warnings across the board Change-Id: I166109dc05d3323b92cd2a42f0c7e6009950e15d
2017-02-08 16:07:40 +00:00
#include <string.h>
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
#include <inttypes.h>
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
#include <osmocom/core/tdef.h>
VTY: cosmetic: use osmo_talloc_replace_string() Change-Id: Id09c7d24b48ddecfa96404c3e75330465a11f830
2019-11-30 13:15:22 +00:00
#include <osmocom/core/utils.h>
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
#include <osmocom/vty/tdef_vty.h>
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
#include <osmocom/vty/logging.h>
stats: Enable stats subsystem Sponsored-by: On-Waves ehf
2015-11-10 14:32:00 +00:00
#include <osmocom/vty/stats.h>
vty: Fix warnings about undeclared functions This commit adds missing includes to pcu_vty.c and fixes the llist_head type (missing struct keyword) used by tbf_print_vty_info. Sponsored-by: On-Waves ehf
2015-04-30 13:59:01 +00:00
#include <osmocom/vty/misc.h>
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
#include <osmocom/core/linuxlist.h>
misc: Add missing include for the rate counter pcu_vty.c:285:2: warning: implicit declaration of function 'vty_out_rate_ctr_group' is invalid in C99 [-Wimplicit-function-declaration] vty_out_rate_ctr_group(vty, "", bts_main_data_stats()); ^
2014-07-02 12:57:47 +00:00
#include <osmocom/core/rate_ctr.h>
Introduce NACC support A new nacc_fsm is introduced per MS object, with its partner priv structure struct nacc_fsm_ctx, which exists and is available in the MS object only during the duration of the NACC procedure. The NACC context is created on an MS whenever a Pkt Cell Change Notification is received on Uplink RLCMAC, which asks for neighbor information of a given ARFCN+BSIC. First, the target ARFCN+BSIC needs to be translated into a CGI-PS (RAC+CI) address. That's done by asking the BSC through the Neighbour Resolution Service available in osmo-bsc using the CTRL interface. Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO request against the SGSN (which will route the request as needed), and wait for a response containing the SI bits from the target cell. After the SI are received, the scheduler is instructed to eventually poll a TBF for the MS originating the CCN, so that we can send the SI encapsulated into multiple Packet Neighbor Cell Data messages on the downlink. One all the SI bits are sent, the scheduler is instructed to send a Packet Cell Change Continue message. Once the message above has been sent, the FSM autodestroys itself. Caches are also introduced in this patch which allows for re-using recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO respectively. Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
2021-01-21 17:46:13 +00:00
#include <osmocom/ctrl/ports.h>
Add pcu-socket vty config osmo-bts already supports configuring a different path for the bts<->pcu socket by using the 'pcu-socket' config field. Change-Id: I9b3e1171da467519750b201849ec892a1e318129
2017-08-08 13:03:50 +00:00
#include <osmocom/pcu/pcuif_proto.h>
Use the new NS2 lib Depends: Id7edb8feb96436ba170383fc62d43ceb16955d53 (libosmocore) Depends: I2a9dcd14f4ad16211c0f6d98812ad4a13e910c2a (libosmocore) Change-Id: Ib389925cf5c9f18951af6242c31ea70476218e9a
2020-09-16 19:52:02 +00:00
#include <osmocom/gprs/gprs_ns2.h>
VTY implementation
2012-07-12 12:31:57 +00:00
#include "pcu_vty.h"
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
#include "gprs_rlcmac.h"
Move PDCH-related functions into separate files The PDCH class and corresponding functions are rather self-contained and independent from BTS implementation. Let's move them into separate file to make bts.cpp more manageable. As additional benefit it allow us to somewhat untangle all the different cross-dependent includes. Change-Id: Ie05e25361e6741a81b024679f9675c98d4923683 Related: OS#1539
2018-02-19 16:17:28 +00:00
#include <pdch.h>
bts: Move struct gprs_rlcmac_bts and other structs into a bts.h Begin to make the BTS a real C++ object with real responsibilities. The biggest issue will be the pcu_vty.c that might not like C++ at all.
2013-10-17 15:01:54 +00:00
#include "bts.h"
vty: Fix warnings about undeclared functions This commit adds missing includes to pcu_vty.c and fixes the llist_head type (missing struct keyword) used by tbf_print_vty_info. Sponsored-by: On-Waves ehf
2015-04-30 13:59:01 +00:00
#include "tbf.h"
vty: Add a file for C++ functions Currently the pcu_vty.c doesn't compile with C++. Thus C++ object cannot be access directly there. This commit adds a helper C++ file that exports all functions with C calling conventions and naming to work around that limitation until the transition of pcu_vty.c is completed. Sponsored-by: On-Waves ehf
2015-06-04 07:42:14 +00:00
#include "pcu_vty_functions.h"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
#define X(x) (1 << x)
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
extern void *tall_pcu_ctx;
static const struct value_string pcu_gsmtap_categ_names[] = {
{ PCU_GSMTAP_C_DL_UNKNOWN, "dl-unknown" },
{ PCU_GSMTAP_C_DL_DUMMY, "dl-dummy" },
{ PCU_GSMTAP_C_DL_CTRL, "dl-ctrl" },
{ PCU_GSMTAP_C_DL_DATA_GPRS, "dl-data-gprs" },
{ PCU_GSMTAP_C_DL_DATA_EGPRS, "dl-data-egprs" },
GSMTAP: Ad PTCCH as separate gsmtap category This allows us to send GSMTAP for PTCCH only if requested by user/vty Change-Id: Id720f4bebdce7f6152fbddddbe05036638c5866e
2017-07-29 11:42:27 +00:00
{ PCU_GSMTAP_C_DL_PTCCH, "dl-ptcch" },
Log AGCH and PCH blocks using GSMTAP Change-Id: I4d62f98801af1b0a290d3dd35bd213ccf3151035
2019-09-30 17:07:16 +00:00
{ PCU_GSMTAP_C_DL_AGCH, "dl-agch" },
{ PCU_GSMTAP_C_DL_PCH, "dl-pch" },
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
{ PCU_GSMTAP_C_UL_UNKNOWN, "ul-unknown" },
{ PCU_GSMTAP_C_UL_DUMMY, "ul-dummy" },
{ PCU_GSMTAP_C_UL_CTRL, "ul-ctrl" },
{ PCU_GSMTAP_C_UL_DATA_GPRS, "ul-data-gprs" },
{ PCU_GSMTAP_C_UL_DATA_EGPRS, "ul-data-egprs" },
Log RACH Requests using GSMTAP Change-Id: Ib686a49e8c630808c30bede5810cd65fc045954a
2019-09-30 16:33:14 +00:00
{ PCU_GSMTAP_C_UL_RACH, "ul-rach" },
bts: add send_gsmtap_rach(), also send PTCCH/U over GSMTAP Change-Id: I5cc4c3d2522215a31924121f83fcc2ac9ac6fe9c
2020-06-10 17:26:15 +00:00
{ PCU_GSMTAP_C_UL_PTCCH, "ul-ptcch" },
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
{ 0, NULL }
};
static const struct value_string pcu_gsmtap_categ_help[] = {
{ PCU_GSMTAP_C_DL_UNKNOWN, "Unknown / Unparseable / Erroneous Downlink Blocks" },
{ PCU_GSMTAP_C_DL_DUMMY, "Downlink Dummy Blocks" },
{ PCU_GSMTAP_C_DL_CTRL, "Downlink Control Blocks" },
{ PCU_GSMTAP_C_DL_DATA_GPRS, "Downlink Data Blocks (GPRS)" },
{ PCU_GSMTAP_C_DL_DATA_EGPRS, "Downlink Data Blocks (EGPRS)" },
GSMTAP: Ad PTCCH as separate gsmtap category This allows us to send GSMTAP for PTCCH only if requested by user/vty Change-Id: Id720f4bebdce7f6152fbddddbe05036638c5866e
2017-07-29 11:42:27 +00:00
{ PCU_GSMTAP_C_DL_PTCCH, "Downlink PTCCH Blocks" },
Log AGCH and PCH blocks using GSMTAP Change-Id: I4d62f98801af1b0a290d3dd35bd213ccf3151035
2019-09-30 17:07:16 +00:00
{ PCU_GSMTAP_C_DL_AGCH, "Downlink AGCH Blocks" },
{ PCU_GSMTAP_C_DL_PCH, "Downlink PCH Blocks" },
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
{ PCU_GSMTAP_C_UL_UNKNOWN, "Unknown / Unparseable / Erroneous Downlink Blocks" },
{ PCU_GSMTAP_C_UL_DUMMY, "Uplink Dummy Blocks" },
{ PCU_GSMTAP_C_UL_CTRL, "Uplink Control Blocks" },
{ PCU_GSMTAP_C_UL_DATA_GPRS, "Uplink Data Blocks (GPRS)" },
{ PCU_GSMTAP_C_UL_DATA_EGPRS, "Uplink Data Blocks (EGPRS)" },
Log RACH Requests using GSMTAP Change-Id: Ib686a49e8c630808c30bede5810cd65fc045954a
2019-09-30 16:33:14 +00:00
{ PCU_GSMTAP_C_UL_RACH, "Uplink RACH Bursts" },
bts: add send_gsmtap_rach(), also send PTCCH/U over GSMTAP Change-Id: I5cc4c3d2522215a31924121f83fcc2ac9ac6fe9c
2020-06-10 17:26:15 +00:00
{ PCU_GSMTAP_C_UL_PTCCH, "Uplink PTCCH Bursts" },
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
{ 0, NULL }
};
DEFUN(cfg_pcu_gsmtap_categ, cfg_pcu_gsmtap_categ_cmd, "HIDDEN", "HIDDEN")
{
int categ;
categ = get_string_value(pcu_gsmtap_categ_names, argv[0]);
if (categ < 0)
return CMD_WARNING;
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->gsmtap_categ_mask |= (1 << categ);
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
return CMD_SUCCESS;
}
DEFUN(cfg_pcu_no_gsmtap_categ, cfg_pcu_no_gsmtap_categ_cmd, "HIDDEN", "HIDDEN")
{
int categ;
categ = get_string_value(pcu_gsmtap_categ_names, argv[0]);
if (categ < 0)
return CMD_WARNING;
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->gsmtap_categ_mask &= ~(1 << categ);
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
return CMD_SUCCESS;
}
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
static struct cmd_node pcu_node = {
(enum node_type) PCU_NODE,
vty: Use libosmocore VTY standards This commit applies to following changes to pcu_vty.c: - Use vty_install_default() instead of install_default() - Add a blank after the '#' of the prompt - Rename the 'pcu' configuration node to 'config-pcu' Sponsored-by: On-Waves ehf
2015-04-09 13:45:24 +00:00
"%s(config-pcu)# ",
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
1,
};
static int config_write_pcu(struct vty *vty)
{
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
unsigned int i;
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
vty_out(vty, "pcu%s", VTY_NEWLINE);
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
vty_out(vty, " flow-control-interval %d%s", the_pcu->vty.fc_interval,
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
VTY_NEWLINE);
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
if (the_pcu->vty.fc_bvc_bucket_size)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
vty_out(vty, " flow-control force-bvc-bucket-size %d%s",
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_bucket_size, VTY_NEWLINE);
if (the_pcu->vty.fc_bvc_leak_rate)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
vty_out(vty, " flow-control force-bvc-leak-rate %d%s",
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_leak_rate, VTY_NEWLINE);
if (the_pcu->vty.fc_ms_bucket_size)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
vty_out(vty, " flow-control force-ms-bucket-size %d%s",
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_bucket_size, VTY_NEWLINE);
if (the_pcu->vty.fc_ms_leak_rate)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
vty_out(vty, " flow-control force-ms-leak-rate %d%s",
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_leak_rate, VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->vty.force_initial_cs) {
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
if (the_pcu->vty.initial_cs_ul == the_pcu->vty.initial_cs_dl)
vty_out(vty, " cs %d%s", the_pcu->vty.initial_cs_dl,
Allow setting of seperate coding schemes for uplink and downlink
2012-10-03 12:21:36 +00:00
VTY_NEWLINE);
else
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
vty_out(vty, " cs %d %d%s", the_pcu->vty.initial_cs_dl,
the_pcu->vty.initial_cs_ul, VTY_NEWLINE);
misc: Add {} to avoid nested if/if/else ambigiouty pcu_vty.c:89:3: warning: add explicit braces to avoid dangling else [-Wdangling-else] else
2014-07-02 12:55:17 +00:00
}
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->vty.max_cs_dl && the_pcu->vty.max_cs_ul) {
if (the_pcu->vty.max_cs_ul == the_pcu->vty.max_cs_dl)
vty_out(vty, " cs max %d%s", the_pcu->vty.max_cs_dl,
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
VTY_NEWLINE);
else
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
vty_out(vty, " cs max %d %d%s", the_pcu->vty.max_cs_dl,
the_pcu->vty.max_cs_ul, VTY_NEWLINE);
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
}
Move cs_adj* fields from BTS to PCU Change-Id: I2b00a83279dccd4feeeeb95e34878c4405e7972c
2021-01-14 12:17:01 +00:00
if (the_pcu->vty.cs_adj_enabled)
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
vty_out(vty, " cs threshold %d %d%s",
Move cs_adj* fields from BTS to PCU Change-Id: I2b00a83279dccd4feeeeb95e34878c4405e7972c
2021-01-14 12:17:01 +00:00
the_pcu->vty.cs_adj_lower_limit, the_pcu->vty.cs_adj_upper_limit,
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
VTY_NEWLINE);
else
vty_out(vty, " no cs threshold%s", VTY_NEWLINE);
Move cs_downgrade_threshold field from BTS to PCU Change-Id: I3e1c65eb3cccff565d5d84588bdce93a47909a0f
2021-01-14 12:20:55 +00:00
if (the_pcu->vty.cs_downgrade_threshold)
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
vty_out(vty, " cs downgrade-threshold %d%s",
Move cs_downgrade_threshold field from BTS to PCU Change-Id: I3e1c65eb3cccff565d5d84588bdce93a47909a0f
2021-01-14 12:20:55 +00:00
the_pcu->vty.cs_downgrade_threshold, VTY_NEWLINE);
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
else
vty_out(vty, " no cs downgrade-threshold%s", VTY_NEWLINE);
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
vty_out(vty, " cs link-quality-ranges cs1 %d cs2 %d %d cs3 %d %d cs4 %d%s",
Move (m)cs_lqual_ranges fields from BTS to PCU Change-Id: I39e2fc7e229851610d797c594d84902af6079411
2021-01-14 12:30:04 +00:00
the_pcu->vty.cs_lqual_ranges[0].high,
the_pcu->vty.cs_lqual_ranges[1].low,
the_pcu->vty.cs_lqual_ranges[1].high,
the_pcu->vty.cs_lqual_ranges[2].low,
the_pcu->vty.cs_lqual_ranges[2].high,
the_pcu->vty.cs_lqual_ranges[3].low,
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
VTY_NEWLINE);
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
vty_out(vty, " mcs link-quality-ranges mcs1 %d mcs2 %d %d mcs3 %d %d mcs4 %d %d mcs5 %d %d mcs6 %d %d mcs7 %d %d mcs8 %d %d mcs9 %d%s",
Move (m)cs_lqual_ranges fields from BTS to PCU Change-Id: I39e2fc7e229851610d797c594d84902af6079411
2021-01-14 12:30:04 +00:00
the_pcu->vty.mcs_lqual_ranges[0].high,
the_pcu->vty.mcs_lqual_ranges[1].low,
the_pcu->vty.mcs_lqual_ranges[1].high,
the_pcu->vty.mcs_lqual_ranges[2].low,
the_pcu->vty.mcs_lqual_ranges[2].high,
the_pcu->vty.mcs_lqual_ranges[3].low,
the_pcu->vty.mcs_lqual_ranges[3].high,
the_pcu->vty.mcs_lqual_ranges[4].low,
the_pcu->vty.mcs_lqual_ranges[4].high,
the_pcu->vty.mcs_lqual_ranges[5].low,
the_pcu->vty.mcs_lqual_ranges[5].high,
the_pcu->vty.mcs_lqual_ranges[6].low,
the_pcu->vty.mcs_lqual_ranges[6].high,
the_pcu->vty.mcs_lqual_ranges[7].low,
the_pcu->vty.mcs_lqual_ranges[7].high,
the_pcu->vty.mcs_lqual_ranges[8].low,
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->vty.force_initial_mcs) {
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
if (the_pcu->vty.initial_mcs_ul == the_pcu->vty.initial_mcs_dl)
vty_out(vty, " mcs %d%s", the_pcu->vty.initial_mcs_dl,
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
VTY_NEWLINE);
else
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
vty_out(vty, " mcs %d %d%s", the_pcu->vty.initial_mcs_dl,
the_pcu->vty.initial_mcs_ul, VTY_NEWLINE);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
}
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->vty.max_mcs_dl && the_pcu->vty.max_mcs_ul) {
if (the_pcu->vty.max_mcs_ul == the_pcu->vty.max_mcs_dl)
vty_out(vty, " mcs max %d%s", the_pcu->vty.max_mcs_dl,
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
VTY_NEWLINE);
else
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
vty_out(vty, " mcs max %d %d%s", the_pcu->vty.max_mcs_dl,
the_pcu->vty.max_mcs_ul, VTY_NEWLINE);
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
}
Move ws_* fields from BTS to PCU Change-Id: I997bc52f0d924c8f2a0b1d6cf23af98828ad4258
2021-01-14 13:30:03 +00:00
vty_out(vty, " window-size %d %d%s", the_pcu->vty.ws_base, the_pcu->vty.ws_pdch,
edge: Make window size configurable Currently the window size is fixed to 64 even for EGPRS. Support dynamic window sizes depending on the number of PDCH. The WS can be set to b + f * N_PDCH. If the result is not valid according to TS 44.060, Table 9.1.9.2.1, the value will be corrected to use the next lower valid value (or 64). The following VTY commands are added (config-pcu node): window-size <0-1024> set base (b) value and leave f unchanged window-size <0-1024> <0-256> set base (b) and factor (f) Sponsored-by: On-Waves ehf
2016-01-19 14:53:30 +00:00
VTY_NEWLINE);
Move dl_arq_type field from BTS to PCU Change-Id: I0b82ab59edd58d60e5581c707dc49f58de0ba203
2021-01-14 12:08:02 +00:00
if (the_pcu->vty.dl_arq_type == EGPRS_ARQ2)
vty_out(vty, " egprs dl arq-type arq2%s", VTY_NEWLINE);
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
if (the_pcu->vty.force_llc_lifetime == 0xffff)
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
vty_out(vty, " queue lifetime infinite%s", VTY_NEWLINE);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
else if (the_pcu->vty.force_llc_lifetime)
vty_out(vty, " queue lifetime %d%s", the_pcu->vty.force_llc_lifetime,
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
VTY_NEWLINE);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
if (the_pcu->vty.llc_discard_csec)
vty_out(vty, " queue hysteresis %d%s", the_pcu->vty.llc_discard_csec,
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
VTY_NEWLINE);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
if (the_pcu->vty.llc_idle_ack_csec)
vty_out(vty, " queue idle-ack-delay %d%s", the_pcu->vty.llc_idle_ack_csec,
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
VTY_NEWLINE);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
if (the_pcu->vty.llc_codel_interval_msec == LLC_CODEL_USE_DEFAULT)
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
vty_out(vty, " queue codel%s", VTY_NEWLINE);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
else if (the_pcu->vty.llc_codel_interval_msec == LLC_CODEL_DISABLE)
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
vty_out(vty, " no queue codel%s", VTY_NEWLINE);
else
vty_out(vty, " queue codel interval %d%s",
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_codel_interval_msec/10, VTY_NEWLINE);
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->alloc_algorithm == alloc_algorithm_a)
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
vty_out(vty, " alloc-algorithm a%s", VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->alloc_algorithm == alloc_algorithm_b)
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
vty_out(vty, " alloc-algorithm b%s", VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->alloc_algorithm == alloc_algorithm_dynamic)
alloc: Add 'dynamic' allocation algorithm The idea behind this meta algorithm is to automatically select one of the other algorithms based on the system state. Basically algorithm B will be selected if the PDCH usage is low to improve throughput and latency. Algorithm A will be selected to support more concurrent MS. This commit adds a first simple state-less version of this algorithm that always tries B first and only if that fails A is tried afterwards. The following VTY command is added to the 'pcu' node: - alloc-algorithm dynamic Ticket: #1934 Sponsored-by: On-Waves ehf
2015-07-14 11:31:48 +00:00
vty_out(vty, " alloc-algorithm dynamic%s", VTY_NEWLINE);
Move force_two_phase field from BTS to PCU Change-Id: I68a6e032f725cde87992b99f039c5280e912faf7
2021-01-14 11:48:50 +00:00
if (the_pcu->vty.force_two_phase)
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
vty_out(vty, " two-phase-access%s", VTY_NEWLINE);
Use ALPHA value received in SI13 from PCUIF The old VTY command is marked as deprecated and still overrides the use in case it's used. Related: SYS#5358 Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
2021-02-09 17:47:34 +00:00
if (the_pcu->vty.force_alpha != (uint8_t)-1)
vty_out(vty, " alpha %u%s", the_pcu->vty.force_alpha, VTY_NEWLINE);
Move alpha,gamma fields from BTS to PCU Change-Id: I2fdd9c8a7393157183fff64084bb10e2a3b1dc63
2021-01-14 11:53:53 +00:00
vty_out(vty, " gamma %d%s", the_pcu->vty.gamma * 2, VTY_NEWLINE);
Move dl_tbf_preemptive_retransmission field from BTS to PCU Change-Id: I3ab32fcafe83f3ecb116a5b8a05f58f3fddc5451
2021-01-14 11:56:58 +00:00
if (!the_pcu->vty.dl_tbf_preemptive_retransmission)
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
vty_out(vty, " no dl-tbf-preemptive-retransmission%s", VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (strcmp(the_pcu->pcu_sock_path, PCU_SOCK_DEFAULT))
vty_out(vty, " pcu-socket %s%s", the_pcu->pcu_sock_path, VTY_NEWLINE);
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
for (i = 0; i < 32; i++) {
Fix: left shift cannot be repesented in type int Caught by ASan: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' Change-Id: I30aed795d027dc063f06e08c8455bad2dd92cf24
2021-03-24 13:26:39 +00:00
uint32_t cs = ((uint32_t)1 << i);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
if (the_pcu->gsmtap_categ_mask & cs) {
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
vty_out(vty, " gsmtap-category %s%s",
get_value_string(pcu_gsmtap_categ_names, i), VTY_NEWLINE);
}
}
follow gprs_ns2 API enum changes All gprs_ns2 enums have now GPRS_NS2 as prefix. Depends-on: I548ff12f7277cbb7e1a630a3dc02b738ce89be72 (libosmocore) Change-Id: Ifdc7956318c07d680feab33c22bc2c6f20927bf9
2021-01-25 19:28:38 +00:00
if (the_pcu->vty.ns_dialect == GPRS_NS2_DIALECT_SNS)
Optionally Use the NS Sub-Network-Service (SNS) on Gb This change add support for the recently-introduced GPRS Gb interface auto-configuration using the NS IP Sub-Network Service (SNS) procedures. It requires a Change-Id I84786c3b43a8ae34ef3b3ba84b33c90042d234ea of libosmocore. Related: OS#3372 Depends: I84786c3b43a8ae34ef3b3ba84b33c90042d234ea (libosmcore) Change-Id: I256b40ac592d3b6e75dd581bf7b9512f69b11e83
2018-07-05 01:11:17 +00:00
vty_out(vty, " gb-dialect ip-sns%s", VTY_NEWLINE);
else
vty_out(vty, " gb-dialect classic%s", VTY_NEWLINE);
vty: Add configuration for Gb DSCP and socket priority While libosmogb / ns2 supports that natively in the VTY, the PCU doesn't want to use the complexities of the full NS2 vty. Change-Id: I7bfbad46582e65e5ad2ac0cc66545538bc632df8 Related: SYS#5427
2021-04-29 20:02:47 +00:00
if (the_pcu->vty.ns_ip_dscp != -1)
vty_out(vty, " gb ip-dscp %d%s", the_pcu->vty.ns_ip_dscp, VTY_NEWLINE);
if (the_pcu->vty.ns_priority != -1)
vty_out(vty, " gb socket-priority %d%s", the_pcu->vty.ns_priority, VTY_NEWLINE);
vty: Write 'neighbor resolution' config to file Fixes: c0a250d17d79e08763f77cdf58e970dc2e65e7d3 Related: SYS#4909 Change-Id: I44eef3826939e05ba88e0c5a67e1fef535582ba7
2021-02-17 19:24:59 +00:00
if (the_pcu->vty.neigh_ctrl_addr) {
vty_out(vty, " neighbor resolution %s %u%s",
the_pcu->vty.neigh_ctrl_addr, the_pcu->vty.neigh_ctrl_port, VTY_NEWLINE);
}
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
osmo_tdef_vty_write(vty, the_pcu->T_defs, " timer ");
vty: Fix osmo_tdef timers not listed in write config Change-Id: I5c7ae18919e4b016505aa01eea6694d8a3f5df5f
2019-09-26 16:25:35 +00:00
vty: drop unused function Change-Id: I01f3773ca6a9b6d4e28ca2f59c944c6d48918dd1
2018-01-30 16:53:02 +00:00
return CMD_SUCCESS;
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
}
/* per-BTS configuration */
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu,
cfg_pcu_cmd,
"pcu",
"BTS specific configure",
CMD_ATTR_IMMEDIATE)
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
{
vty->node = PCU_NODE;
return CMD_SUCCESS;
}
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
#define EGPRS_STR "EGPRS configuration\n"
Enable egprs support through PCUIF from BTS/BSC This VTY command was added due to EGPRS being introduced later as an experimental feature. It's no longer needed and causes more problems than goodness (since people sometimes forgets to enable it). Let's rather simply enable EGPRS support based on what BTS/BSC requests over PCUIF. Related: OS#4544 Change-Id: Ic80970a136361584da9c912252a07e7c3c9d85d0
2020-10-30 16:15:32 +00:00
DEFUN_DEPRECATED(cfg_pcu_egprs,
cfg_pcu_egprs_cmd,
"egprs only",
EGPRS_STR "Use EGPRS and disable plain GPRS\n")
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
{
Enable egprs support through PCUIF from BTS/BSC This VTY command was added due to EGPRS being introduced later as an experimental feature. It's no longer needed and causes more problems than goodness (since people sometimes forgets to enable it). Let's rather simply enable EGPRS support based on what BTS/BSC requests over PCUIF. Related: OS#4544 Change-Id: Ic80970a136361584da9c912252a07e7c3c9d85d0
2020-10-30 16:15:32 +00:00
vty_out (vty, "'egprs only' is deprecated, egprs support is controled from BTS/BSC config, this is now a no-op%s", VTY_NEWLINE);
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
return CMD_SUCCESS;
}
Enable egprs support through PCUIF from BTS/BSC This VTY command was added due to EGPRS being introduced later as an experimental feature. It's no longer needed and causes more problems than goodness (since people sometimes forgets to enable it). Let's rather simply enable EGPRS support based on what BTS/BSC requests over PCUIF. Related: OS#4544 Change-Id: Ic80970a136361584da9c912252a07e7c3c9d85d0
2020-10-30 16:15:32 +00:00
DEFUN_DEPRECATED(cfg_pcu_no_egprs,
cfg_pcu_no_egprs_cmd,
"no egprs",
NO_STR EGPRS_STR)
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
{
Enable egprs support through PCUIF from BTS/BSC This VTY command was added due to EGPRS being introduced later as an experimental feature. It's no longer needed and causes more problems than goodness (since people sometimes forgets to enable it). Let's rather simply enable EGPRS support based on what BTS/BSC requests over PCUIF. Related: OS#4544 Change-Id: Ic80970a136361584da9c912252a07e7c3c9d85d0
2020-10-30 16:15:32 +00:00
vty_out (vty, "'no egprs only' is deprecated, egprs support is controled from BTS/BSC config, this is now a no-op%s", VTY_NEWLINE);
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_interval,
cfg_pcu_fc_interval_cmd,
"flow-control-interval <1-10>",
"Interval between sending subsequent Flow Control PDUs\n"
"Interval time in seconds\n",
CMD_ATTR_IMMEDIATE)
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_interval = atoi(argv[0]);
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
return CMD_SUCCESS;
}
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
#define FC_STR "BSSGP Flow Control configuration\n"
#define FC_BMAX_STR(who) "Force a fixed value for the " who " bucket size\n"
#define FC_LR_STR(who) "Force a fixed value for the " who " leak rate\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_bvc_bucket_size,
cfg_pcu_fc_bvc_bucket_size_cmd,
"flow-control force-bvc-bucket-size <1-6553500>",
FC_STR FC_BMAX_STR("BVC") "Bucket size in octets\n",
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_bucket_size = atoi(argv[0]);
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_fc_bvc_bucket_size,
cfg_pcu_no_fc_bvc_bucket_size_cmd,
"no flow-control force-bvc-bucket-size",
NO_STR FC_STR FC_BMAX_STR("BVC"),
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_bucket_size = 0;
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_bvc_leak_rate,
cfg_pcu_fc_bvc_leak_rate_cmd,
"flow-control force-bvc-leak-rate <1-6553500>",
FC_STR FC_LR_STR("BVC") "Leak rate in bit/s\n",
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_leak_rate = atoi(argv[0]);
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_fc_bvc_leak_rate,
cfg_pcu_no_fc_bvc_leak_rate_cmd,
"no flow-control force-bvc-leak-rate",
NO_STR FC_STR FC_LR_STR("BVC"),
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bvc_leak_rate = 0;
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_ms_bucket_size,
cfg_pcu_fc_ms_bucket_size_cmd,
"flow-control force-ms-bucket-size <1-6553500>",
FC_STR FC_BMAX_STR("default MS") "Bucket size in octets\n",
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_bucket_size = atoi(argv[0]);
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_fc_ms_bucket_size,
cfg_pcu_no_fc_ms_bucket_size_cmd,
"no flow-control force-ms-bucket-size",
NO_STR FC_STR FC_BMAX_STR("default MS"),
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_bucket_size = 0;
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_ms_leak_rate,
cfg_pcu_fc_ms_leak_rate_cmd,
"flow-control force-ms-leak-rate <1-6553500>",
FC_STR FC_LR_STR("default MS") "Leak rate in bit/s\n",
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_leak_rate = atoi(argv[0]);
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_fc_ms_leak_rate,
cfg_pcu_no_fc_ms_leak_rate_cmd,
"no flow-control force-ms-leak-rate",
NO_STR FC_STR FC_LR_STR("default MS"),
CMD_ATTR_IMMEDIATE)
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_ms_leak_rate = 0;
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
return CMD_SUCCESS;
}
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
#define FC_BTIME_STR "Set target downlink maximum queueing time (only affects the advertised bucket size)\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_fc_bucket_time,
cfg_pcu_fc_bucket_time_cmd,
"flow-control bucket-time <1-65534>",
FC_STR FC_BTIME_STR "Time in centi-seconds\n",
CMD_ATTR_IMMEDIATE)
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bucket_time = atoi(argv[0]);
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_fc_bucket_time,
cfg_pcu_no_fc_bucket_time_cmd,
"no flow-control bucket-time",
NO_STR FC_STR FC_BTIME_STR,
CMD_ATTR_IMMEDIATE)
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
{
Move fc_* fields from BTS to PCU Change-Id: I816d49e732d0fc7a3c9aa1f0e9a83b83d25e6a32
2021-01-14 13:03:17 +00:00
the_pcu->vty.fc_bucket_time = 0;
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
return CMD_SUCCESS;
}
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
#define CS_STR "Coding Scheme configuration\n"
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_cs,
cfg_pcu_cs_cmd,
"cs <1-4> [<1-4>]",
CS_STR
"Initial CS value to be used (overrides BTS config)\n"
"Use a different initial CS value for the uplink",
CMD_ATTR_IMMEDIATE)
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
{
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
uint8_t cs_dl, cs_ul;
cs_dl = atoi(argv[0]);
Allow setting of seperate coding schemes for uplink and downlink
2012-10-03 12:21:36 +00:00
if (argc > 1)
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
cs_ul = atoi(argv[1]);
Allow setting of seperate coding schemes for uplink and downlink
2012-10-03 12:21:36 +00:00
else
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
cs_ul = cs_dl;
the_pcu->vty.force_initial_cs = true;
gprs_pcu_set_initial_cs(the_pcu, cs_dl, cs_ul);
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_cs,
cfg_pcu_no_cs_cmd,
"no cs",
NO_STR CS_STR,
CMD_ATTR_IMMEDIATE)
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
{
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->vty.force_initial_cs = false;
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
gprs_pcu_set_initial_cs(the_pcu, 0, 0);
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
return CMD_SUCCESS;
}
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
#define CS_MAX_STR "Set maximum values for adaptive CS selection (overrides BTS config)\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_cs_max,
cfg_pcu_cs_max_cmd,
"cs max <1-4> [<1-4>]",
CS_STR
CS_MAX_STR
"Maximum CS value to be used\n"
"Use a different maximum CS value for the uplink",
CMD_ATTR_IMMEDIATE)
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
{
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
uint8_t cs_dl = atoi(argv[0]);
uint8_t cs_ul;
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
if (argc > 1)
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
cs_ul = atoi(argv[1]);
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
else
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
cs_ul = cs_dl;
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
gprs_pcu_set_max_cs(the_pcu, cs_dl, cs_ul);
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_cs_max,
cfg_pcu_no_cs_max_cmd,
"no cs max",
NO_STR CS_STR CS_MAX_STR,
CMD_ATTR_IMMEDIATE)
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
{
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
gprs_pcu_set_max_cs(the_pcu, 0, 0);
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
return CMD_SUCCESS;
}
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
#define MCS_STR "Modulation and Coding Scheme configuration (EGPRS)\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_mcs,
cfg_pcu_mcs_cmd,
"mcs <1-9> [<1-9>]",
MCS_STR
"Initial MCS value to be used (default 1)\n"
"Use a different initial MCS value for the uplink",
CMD_ATTR_IMMEDIATE)
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
{
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
uint8_t mcs_dl, mcs_ul;
mcs_dl = atoi(argv[0]);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
if (argc > 1)
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
mcs_ul = atoi(argv[1]);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
else
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
mcs_ul = mcs_dl;
the_pcu->vty.force_initial_mcs = true;
gprs_pcu_set_initial_mcs(the_pcu, mcs_dl, mcs_ul);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_mcs,
cfg_pcu_no_mcs_cmd,
"no mcs",
NO_STR MCS_STR,
CMD_ATTR_IMMEDIATE)
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
{
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->vty.force_initial_mcs = false;
Fix configuration mess of initial_cs/mcs between PCUIF and VTY Both values (optionally) set (forced) by VTY and the values received from PCUIF were stored in the same variable, meaning that for instance the PCUIF values wouldn't really be used if someone applied eg "no cs" during runtime. This commit does something similar to what was already done for the max_(m)cs fields. We store PCUIF values in one place and VTY ones in another place, and then trigger a bts object internal process to find out exactly which initial CS should it be using. Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
2021-01-14 15:20:57 +00:00
gprs_pcu_set_initial_mcs(the_pcu, 0, 0);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_mcs_max,
cfg_pcu_mcs_max_cmd,
"mcs max <1-9> [<1-9>]",
MCS_STR
CS_MAX_STR
"Maximum MCS value to be used\n"
"Use a different maximum MCS value for the uplink",
CMD_ATTR_IMMEDIATE)
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
{
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
uint8_t mcs_dl = atoi(argv[0]);
uint8_t mcs_ul;
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
if (argc > 1)
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
mcs_ul = atoi(argv[1]);
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
else
Take into account BTS supported (M)CS values when retrieving the maximum Change-Id: I2d3a8bbae2f9887400ce56d2f8303ea30abaecfa
2020-10-30 17:35:54 +00:00
mcs_ul = mcs_dl;
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
gprs_pcu_set_max_mcs(the_pcu, mcs_dl, mcs_ul);
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_mcs_max,
cfg_pcu_no_mcs_max_cmd,
"no mcs max",
NO_STR MCS_STR CS_MAX_STR,
CMD_ATTR_IMMEDIATE)
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
{
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
gprs_pcu_set_max_mcs(the_pcu, 0, 0);
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
return CMD_SUCCESS;
}
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
#define DL_STR "downlink specific configuration\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_dl_arq_type,
cfg_pcu_dl_arq_cmd,
"egprs dl arq-type (spb|arq2)",
EGPRS_STR DL_STR "ARQ options\n"
"enable SPB(ARQ1) support\n"
"enable ARQ2 support",
CMD_ATTR_IMMEDIATE)
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
{
if (!strcmp(argv[0], "arq2"))
Move dl_arq_type field from BTS to PCU Change-Id: I0b82ab59edd58d60e5581c707dc49f58de0ba203
2021-01-14 12:08:02 +00:00
the_pcu->vty.dl_arq_type = EGPRS_ARQ2;
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
else
Move dl_arq_type field from BTS to PCU Change-Id: I0b82ab59edd58d60e5581c707dc49f58de0ba203
2021-01-14 12:08:02 +00:00
the_pcu->vty.dl_arq_type = EGPRS_ARQ1;
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_window_size,
cfg_pcu_window_size_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"window-size <0-1024> [<0-256>]",
"Window size configuration (b + N_PDCH * f)\n"
"Base value (b)\n"
"Factor for number of PDCH (f)")
edge: Make window size configurable Currently the window size is fixed to 64 even for EGPRS. Support dynamic window sizes depending on the number of PDCH. The WS can be set to b + f * N_PDCH. If the result is not valid according to TS 44.060, Table 9.1.9.2.1, the value will be corrected to use the next lower valid value (or 64). The following VTY commands are added (config-pcu node): window-size <0-1024> set base (b) value and leave f unchanged window-size <0-1024> <0-256> set base (b) and factor (f) Sponsored-by: On-Waves ehf
2016-01-19 14:53:30 +00:00
{
uint16_t b = atoi(argv[0]);
Move ws_* fields from BTS to PCU Change-Id: I997bc52f0d924c8f2a0b1d6cf23af98828ad4258
2021-01-14 13:30:03 +00:00
the_pcu->vty.ws_base = b;
edge: Make window size configurable Currently the window size is fixed to 64 even for EGPRS. Support dynamic window sizes depending on the number of PDCH. The WS can be set to b + f * N_PDCH. If the result is not valid according to TS 44.060, Table 9.1.9.2.1, the value will be corrected to use the next lower valid value (or 64). The following VTY commands are added (config-pcu node): window-size <0-1024> set base (b) value and leave f unchanged window-size <0-1024> <0-256> set base (b) and factor (f) Sponsored-by: On-Waves ehf
2016-01-19 14:53:30 +00:00
if (argc > 1) {
uint16_t f = atoi(argv[1]);
Move ws_* fields from BTS to PCU Change-Id: I997bc52f0d924c8f2a0b1d6cf23af98828ad4258
2021-01-14 13:30:03 +00:00
the_pcu->vty.ws_pdch = f;
edge: Make window size configurable Currently the window size is fixed to 64 even for EGPRS. Support dynamic window sizes depending on the number of PDCH. The WS can be set to b + f * N_PDCH. If the result is not valid according to TS 44.060, Table 9.1.9.2.1, the value will be corrected to use the next lower valid value (or 64). The following VTY commands are added (config-pcu node): window-size <0-1024> set base (b) value and leave f unchanged window-size <0-1024> <0-256> set base (b) and factor (f) Sponsored-by: On-Waves ehf
2016-01-19 14:53:30 +00:00
}
return CMD_SUCCESS;
}
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
#define QUEUE_STR "Packet queue options\n"
#define LIFETIME_STR "Set lifetime limit of LLC frame in centi-seconds " \
"(overrides the value given by SGSN)\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_queue_lifetime,
cfg_pcu_queue_lifetime_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"queue lifetime <1-65534>",
QUEUE_STR LIFETIME_STR "Lifetime in centi-seconds")
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
{
vty: Fix value range of commands accepting csecs Currently an uint8_t csec variable is used to temporarily store the number of centiseconds which can be set within the range 1 - 65535. This way values above 255 cannot be set properly. This affects the VTY commands "queue lifetime", "queue hysteres", and "queue idle-ack-delay". This commit replaces the uint8_t by an uint16_t. Sponsored-by: On-Waves ehf
2015-04-30 15:55:16 +00:00
uint16_t csec = atoi(argv[0]);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.force_llc_lifetime = csec;
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_queue_lifetime_inf,
cfg_pcu_queue_lifetime_inf_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"queue lifetime infinite",
QUEUE_STR LIFETIME_STR "Infinite lifetime")
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.force_llc_lifetime = 0xffff;
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_no_queue_lifetime,
cfg_pcu_no_queue_lifetime_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"no queue lifetime",
NO_STR QUEUE_STR "Disable lifetime limit of LLC frame (use value given "
"by SGSN)\n")
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.force_llc_lifetime = 0;
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
return CMD_SUCCESS;
}
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
#define QUEUE_HYSTERESIS_STR "Set lifetime hysteresis of LLC frame in centi-seconds " \
"(continue discarding until lifetime-hysteresis is reached)\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_queue_hysteresis,
cfg_pcu_queue_hysteresis_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"queue hysteresis <1-65535>",
QUEUE_STR QUEUE_HYSTERESIS_STR "Hysteresis in centi-seconds")
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
{
vty: Fix value range of commands accepting csecs Currently an uint8_t csec variable is used to temporarily store the number of centiseconds which can be set within the range 1 - 65535. This way values above 255 cannot be set properly. This affects the VTY commands "queue lifetime", "queue hysteres", and "queue idle-ack-delay". This commit replaces the uint8_t by an uint16_t. Sponsored-by: On-Waves ehf
2015-04-30 15:55:16 +00:00
uint16_t csec = atoi(argv[0]);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_discard_csec = csec;
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_no_queue_hysteresis,
cfg_pcu_no_queue_hysteresis_cmd,
X(PCU_VTY_ATTR_NEW_TBF),
"no queue hysteresis",
NO_STR QUEUE_STR QUEUE_HYSTERESIS_STR)
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_discard_csec = 0;
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
return CMD_SUCCESS;
}
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
#define QUEUE_CODEL_STR "Set CoDel queue management\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_queue_codel,
cfg_pcu_queue_codel_cmd,
X(PCU_VTY_ATTR_NEW_SUBSCR),
"queue codel",
QUEUE_STR QUEUE_CODEL_STR)
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_codel_interval_msec = LLC_CODEL_USE_DEFAULT;
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_queue_codel_interval,
cfg_pcu_queue_codel_interval_cmd,
X(PCU_VTY_ATTR_NEW_SUBSCR),
"queue codel interval <1-1000>",
QUEUE_STR QUEUE_CODEL_STR "Specify interval\n" "Interval in centi-seconds")
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
{
uint16_t csec = atoi(argv[0]);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_codel_interval_msec = 10*csec;
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_no_queue_codel,
cfg_pcu_no_queue_codel_cmd,
X(PCU_VTY_ATTR_NEW_SUBSCR),
"no queue codel",
NO_STR QUEUE_STR QUEUE_CODEL_STR)
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_codel_interval_msec = LLC_CODEL_DISABLE;
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
return CMD_SUCCESS;
}
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
#define QUEUE_IDLE_ACK_STR "Request an ACK after the last DL LLC frame in centi-seconds\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_queue_idle_ack_delay,
cfg_pcu_queue_idle_ack_delay_cmd,
"queue idle-ack-delay <1-65535>",
QUEUE_STR QUEUE_IDLE_ACK_STR "Idle ACK delay in centi-seconds",
CMD_ATTR_IMMEDIATE)
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
{
vty: Fix value range of commands accepting csecs Currently an uint8_t csec variable is used to temporarily store the number of centiseconds which can be set within the range 1 - 65535. This way values above 255 cannot be set properly. This affects the VTY commands "queue lifetime", "queue hysteres", and "queue idle-ack-delay". This commit replaces the uint8_t by an uint16_t. Sponsored-by: On-Waves ehf
2015-04-30 15:55:16 +00:00
uint16_t csec = atoi(argv[0]);
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_idle_ack_csec = csec;
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_queue_idle_ack_delay,
cfg_pcu_no_queue_idle_ack_delay_cmd,
"no queue idle-ack-delay",
NO_STR QUEUE_STR QUEUE_IDLE_ACK_STR,
CMD_ATTR_IMMEDIATE)
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
{
Move llc_* fields from BTS to PCU Change-Id: Iffb916e53fdf99164ad07cd19e4b35a64136307e
2021-01-14 13:45:14 +00:00
the_pcu->vty.llc_idle_ack_csec = 0;
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_alloc,
cfg_pcu_alloc_cmd,
"alloc-algorithm (a|b|dynamic)",
"Select slot allocation algorithm to use when assigning timeslots on "
"PACCH\n"
"Single slot is assigned only\n"
"Multiple slots are assigned for semi-duplex operation\n"
"Dynamically select the algorithm based on the system state\n",
CMD_ATTR_IMMEDIATE)
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
{
switch (argv[0][0]) {
case 'a':
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->alloc_algorithm = alloc_algorithm_a;
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
break;
case 'b':
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->alloc_algorithm = alloc_algorithm_b;
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
break;
alloc: Add 'dynamic' allocation algorithm The idea behind this meta algorithm is to automatically select one of the other algorithms based on the system state. Basically algorithm B will be selected if the PDCH usage is low to improve throughput and latency. Algorithm A will be selected to support more concurrent MS. This commit adds a first simple state-less version of this algorithm that always tries B first and only if that fails A is tried afterwards. The following VTY command is added to the 'pcu' node: - alloc-algorithm dynamic Ticket: #1934 Sponsored-by: On-Waves ehf
2015-07-14 11:31:48 +00:00
default:
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
the_pcu->alloc_algorithm = alloc_algorithm_dynamic;
alloc: Add 'dynamic' allocation algorithm The idea behind this meta algorithm is to automatically select one of the other algorithms based on the system state. Basically algorithm B will be selected if the PDCH usage is low to improve throughput and latency. Algorithm A will be selected to support more concurrent MS. This commit adds a first simple state-less version of this algorithm that always tries B first and only if that fails A is tried afterwards. The following VTY command is added to the 'pcu' node: - alloc-algorithm dynamic Ticket: #1934 Sponsored-by: On-Waves ehf
2015-07-14 11:31:48 +00:00
break;
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
}
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_two_phase,
cfg_pcu_two_phase_cmd,
"two-phase-access",
"Force two phase access when MS requests single phase access\n",
CMD_ATTR_IMMEDIATE)
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
{
Move force_two_phase field from BTS to PCU Change-Id: I68a6e032f725cde87992b99f039c5280e912faf7
2021-01-14 11:48:50 +00:00
the_pcu->vty.force_two_phase = 1;
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_two_phase,
cfg_pcu_no_two_phase_cmd,
"no two-phase-access",
NO_STR "Only use two phase access when requested my MS\n",
CMD_ATTR_IMMEDIATE)
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
{
Move force_two_phase field from BTS to PCU Change-Id: I68a6e032f725cde87992b99f039c5280e912faf7
2021-01-14 11:48:50 +00:00
the_pcu->vty.force_two_phase = 0;
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_alpha,
cfg_pcu_alpha_cmd,
Use ALPHA value received in SI13 from PCUIF The old VTY command is marked as deprecated and still overrides the use in case it's used. Related: SYS#5358 Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
2021-02-09 17:47:34 +00:00
"alpha (si13|<0-10>)",
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
"Alpha parameter for MS power control in units of 0.1 (see TS 05.08) "
"NOTE: Be sure to set Alpha value at System information 13 too.\n"
Use ALPHA value received in SI13 from PCUIF The old VTY command is marked as deprecated and still overrides the use in case it's used. Related: SYS#5358 Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
2021-02-09 17:47:34 +00:00
"Use value received from BSC in System Intormation 13 (default)\n"
"Force Alpha in units of 0.1\n",
CMD_ATTR_IMMEDIATE | CMD_ATTR_DEPRECATED)
Set Alpha and Gamma at assingment messages for power control The initial power control value Alpha must be set in SI13.
2012-09-27 07:20:45 +00:00
{
Use ALPHA value received in SI13 from PCUIF The old VTY command is marked as deprecated and still overrides the use in case it's used. Related: SYS#5358 Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
2021-02-09 17:47:34 +00:00
vty_out(vty, "%% 'alpha <0-10>' is now deprecated: use osmo-bsc's 'gprs power-control alpha <0-10>' instead%s",
VTY_NEWLINE);
if (strcmp(argv[0], "si13") == 0)
the_pcu->vty.force_alpha = (uint8_t) -1;
else
the_pcu->vty.force_alpha = atoi(argv[0]);
Set Alpha and Gamma at assingment messages for power control The initial power control value Alpha must be set in SI13.
2012-09-27 07:20:45 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_gamma,
cfg_pcu_gamma_cmd,
"gamma <0-62>",
"Gamma parameter for MS power control in units of dB (see TS 05.08)\n"
"Gamma in even unit of dBs\n",
CMD_ATTR_IMMEDIATE)
Set Alpha and Gamma at assingment messages for power control The initial power control value Alpha must be set in SI13.
2012-09-27 07:20:45 +00:00
{
Move alpha,gamma fields from BTS to PCU Change-Id: I2fdd9c8a7393157183fff64084bb10e2a3b1dc63
2021-01-14 11:53:53 +00:00
the_pcu->vty.gamma = atoi(argv[0]) / 2;
Set Alpha and Gamma at assingment messages for power control The initial power control value Alpha must be set in SI13.
2012-09-27 07:20:45 +00:00
return CMD_SUCCESS;
}
bts: Start creating statistics inside the BTS code
2013-10-27 08:02:31 +00:00
DEFUN(show_bts_stats,
show_bts_stats_cmd,
"show bts statistics",
SHOW_STR "BTS related functionality\nStatistics\n")
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
vty_out(vty, "BTS%" PRIu8 ":%s", bts->nr, VTY_NEWLINE);
vty_out_rate_ctr_group(vty, " ", bts_rate_counters(bts));
}
bts: Start creating statistics inside the BTS code
2013-10-27 08:02:31 +00:00
return CMD_SUCCESS;
pcu_vty: Add a command to print info about all TBFs
2014-01-15 16:06:51 +00:00
}
vty: Add 'show bts pdch' command This allows to see which channels have been enabled according to PCU. Change-Id: If72e67ba80aab4e0c68408e6996d74d2ff70c322
2020-09-22 15:01:31 +00:00
DEFUN(show_bts_pdch,
show_bts_pdch_cmd,
"show bts pdch",
SHOW_STR "BTS related functionality\nPDCH timeslots\n")
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
pcu_vty_show_bts_pdch(vty, bts);
}
return CMD_SUCCESS;
vty: Add 'show bts pdch' command This allows to see which channels have been enabled according to PCU. Change-Id: If72e67ba80aab4e0c68408e6996d74d2ff70c322
2020-09-22 15:01:31 +00:00
}
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
#define IDLE_TIME_STR "keep an idle DL TBF alive for the time given\n"
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
DEFUN_DEPRECATED(cfg_pcu_dl_tbf_idle_time,
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
cfg_pcu_dl_tbf_idle_time_cmd,
"dl-tbf-idle-time <1-5000>",
IDLE_TIME_STR "idle time in msec")
{
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
vty_out(vty, "%% 'dl-tbf-idle-time' is now deprecated: use 'timer X2031 <val>' instead%s", VTY_NEWLINE);
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
if (osmo_tdef_set(the_pcu->T_defs, -2031, atoi(argv[0]), OSMO_TDEF_MS) < 0)
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
return CMD_WARNING;
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
return CMD_SUCCESS;
}
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
DEFUN_DEPRECATED(cfg_pcu_no_dl_tbf_idle_time,
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
cfg_pcu_no_dl_tbf_idle_time_cmd,
"no dl-tbf-idle-time",
NO_STR IDLE_TIME_STR)
{
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
vty_out(vty, "%% 'no dl-tbf-idle-time' is now deprecated: use 'timer X2031 0' instead%s", VTY_NEWLINE);
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
if (osmo_tdef_set(the_pcu->T_defs, -2031, 0, OSMO_TDEF_MS) < 0)
Use osmo_tdef to implement dl-tbf-idle-time Change-Id: I5e4f0d2f90e643600b7752525d6c2830856c9d3b
2019-09-09 11:41:00 +00:00
return CMD_WARNING;
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
return CMD_SUCCESS;
}
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
#define RETRANSMISSION_STR "retransmit blocks even before the MS had a chance to receive them (better throughput," \
" less readable traces)"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_dl_tbf_preemptive_retransmission,
cfg_pcu_dl_tbf_preemptive_retransmission_cmd,
"dl-tbf-preemptive-retransmission",
RETRANSMISSION_STR " (enabled by default)",
CMD_ATTR_IMMEDIATE)
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
{
Move dl_tbf_preemptive_retransmission field from BTS to PCU Change-Id: I3ab32fcafe83f3ecb116a5b8a05f58f3fddc5451
2021-01-14 11:56:58 +00:00
the_pcu->vty.dl_tbf_preemptive_retransmission = true;
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_dl_tbf_preemptive_retransmission,
cfg_pcu_no_dl_tbf_preemptive_retransmission_cmd,
"no dl-tbf-preemptive-retransmission",
NO_STR RETRANSMISSION_STR,
CMD_ATTR_IMMEDIATE)
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
{
Move dl_tbf_preemptive_retransmission field from BTS to PCU Change-Id: I3ab32fcafe83f3ecb116a5b8a05f58f3fddc5451
2021-01-14 11:56:58 +00:00
the_pcu->vty.dl_tbf_preemptive_retransmission = false;
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
return CMD_SUCCESS;
}
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
#define MS_IDLE_TIME_STR "keep an idle MS object alive for the time given\n"
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
DEFUN_DEPRECATED(cfg_pcu_ms_idle_time,
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
cfg_pcu_ms_idle_time_cmd,
"ms-idle-time <1-7200>",
MS_IDLE_TIME_STR "idle time in sec")
{
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
vty_out(vty, "%% 'ms-idle-time' is now deprecated: use 'timer X2030 <val>' instead%s", VTY_NEWLINE);
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
if (osmo_tdef_set(the_pcu->T_defs, -2030, atoi(argv[0]), OSMO_TDEF_S) < 0)
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
return CMD_WARNING;
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
return CMD_SUCCESS;
}
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
DEFUN_DEPRECATED(cfg_pcu_no_ms_idle_time,
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
cfg_pcu_no_ms_idle_time_cmd,
"no ms-idle-time",
NO_STR MS_IDLE_TIME_STR)
{
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
vty_out(vty, "%% 'no ms-idle-time' is now deprecated: use 'timer X2030 0' instead%s", VTY_NEWLINE);
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
if (osmo_tdef_set(the_pcu->T_defs, -2030, 0, OSMO_TDEF_S) < 0)
Use osmo_tdef to implement ms-idle-time This commit would also remove the option from config_write_pcu() since it's automatically filled in by osmo_tdef, but there was actually a bug because that param was never printed when saving the config... Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
2019-09-09 11:19:06 +00:00
return CMD_WARNING;
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
return CMD_SUCCESS;
}
Clarify (M)CS related VTY attributes Some are used to control (M)CS values for downlink while some do it for uplink. Let's make clear which one is used for what. Take the chance to document the fields a bit better than they were. Some more information about the origin of cs_downgrade_threshold can be found in the commit introducing it: 70b96aa232bd9784a94247bf7b193cb2147ada9d. Related: OS#4286 Change-Id: I4e890e924b094a1937fbd3794de96704cf0421a8
2019-11-28 16:00:44 +00:00
#define CS_ERR_LIMITS_STR "set thresholds for error rate based downlink (M)CS adjustment\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_cs_err_limits,
cfg_pcu_cs_err_limits_cmd,
"cs threshold <0-100> <0-100>",
CS_STR CS_ERR_LIMITS_STR "lower limit in %\n" "upper limit in %\n",
CMD_ATTR_IMMEDIATE)
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
{
uint8_t lower_limit = atoi(argv[0]);
uint8_t upper_limit = atoi(argv[1]);
if (lower_limit > upper_limit) {
vty_out(vty,
"The lower limit must be less than or equal to the "
"upper limit.%s", VTY_NEWLINE);
return CMD_WARNING;
}
Move cs_adj* fields from BTS to PCU Change-Id: I2b00a83279dccd4feeeeb95e34878c4405e7972c
2021-01-14 12:17:01 +00:00
the_pcu->vty.cs_adj_enabled = true;
the_pcu->vty.cs_adj_upper_limit = upper_limit;
the_pcu->vty.cs_adj_lower_limit = lower_limit;
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_cs_err_limits,
cfg_pcu_no_cs_err_limits_cmd,
"no cs threshold",
NO_STR CS_STR CS_ERR_LIMITS_STR,
CMD_ATTR_IMMEDIATE)
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
{
Move cs_adj* fields from BTS to PCU Change-Id: I2b00a83279dccd4feeeeb95e34878c4405e7972c
2021-01-14 12:17:01 +00:00
the_pcu->vty.cs_adj_enabled = false;
the_pcu->vty.cs_adj_upper_limit = 100;
the_pcu->vty.cs_adj_lower_limit = 0;
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
return CMD_SUCCESS;
}
Clarify (M)CS related VTY attributes Some are used to control (M)CS values for downlink while some do it for uplink. Let's make clear which one is used for what. Take the chance to document the fields a bit better than they were. Some more information about the origin of cs_downgrade_threshold can be found in the commit introducing it: 70b96aa232bd9784a94247bf7b193cb2147ada9d. Related: OS#4286 Change-Id: I4e890e924b094a1937fbd3794de96704cf0421a8
2019-11-28 16:00:44 +00:00
#define CS_DOWNGRADE_STR "set threshold for data size based downlink (M)CS downgrade\n"
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_cs_downgrade_thrsh,
cfg_pcu_cs_downgrade_thrsh_cmd,
"cs downgrade-threshold <1-10000>",
CS_STR CS_DOWNGRADE_STR "downgrade if less octets left\n",
CMD_ATTR_IMMEDIATE)
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
{
Move cs_downgrade_threshold field from BTS to PCU Change-Id: I3e1c65eb3cccff565d5d84588bdce93a47909a0f
2021-01-14 12:20:55 +00:00
the_pcu->vty.cs_downgrade_threshold = atoi(argv[0]);
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_no_cs_downgrade_thrsh,
cfg_pcu_no_cs_downgrade_thrsh_cmd,
"no cs downgrade-threshold",
NO_STR CS_STR CS_DOWNGRADE_STR,
CMD_ATTR_IMMEDIATE)
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
{
Move cs_downgrade_threshold field from BTS to PCU Change-Id: I3e1c65eb3cccff565d5d84588bdce93a47909a0f
2021-01-14 12:20:55 +00:00
the_pcu->vty.cs_downgrade_threshold = 0;
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_cs_lqual_ranges,
cfg_pcu_cs_lqual_ranges_cmd,
"cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35>",
CS_STR "Set link quality ranges for each uplink CS\n"
"Set quality range for CS-1 (high value only)\n"
"CS-1 high (dB)\n"
"Set quality range for CS-2\n"
"CS-2 low (dB)\n"
"CS-2 high (dB)\n"
"Set quality range for CS-3\n"
"CS-3 low (dB)\n"
"CS-3 high (dB)\n"
"Set quality range for CS-4 (low value only)\n"
"CS-4 low (dB)\n",
CMD_ATTR_IMMEDIATE)
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
{
uint8_t cs1_high = atoi(argv[0]);
uint8_t cs2_low = atoi(argv[1]);
uint8_t cs2_high = atoi(argv[2]);
uint8_t cs3_low = atoi(argv[3]);
uint8_t cs3_high = atoi(argv[4]);
uint8_t cs4_low = atoi(argv[5]);
Move (m)cs_lqual_ranges fields from BTS to PCU Change-Id: I39e2fc7e229851610d797c594d84902af6079411
2021-01-14 12:30:04 +00:00
the_pcu->vty.cs_lqual_ranges[0].high = cs1_high;
the_pcu->vty.cs_lqual_ranges[1].low = cs2_low;
the_pcu->vty.cs_lqual_ranges[1].high = cs2_high;
the_pcu->vty.cs_lqual_ranges[2].low = cs3_low;
the_pcu->vty.cs_lqual_ranges[2].high = cs3_high;
the_pcu->vty.cs_lqual_ranges[3].low = cs4_low;
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
return CMD_SUCCESS;
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_mcs_lqual_ranges,
cfg_pcu_mcs_lqual_ranges_cmd,
"mcs link-quality-ranges mcs1 <0-35> mcs2 <0-35> <0-35> mcs3 <0-35> <0-35> mcs4 <0-35> <0-35> mcs5 <0-35> <0-35> mcs6 <0-35> <0-35> mcs7 <0-35> <0-35> mcs8 <0-35> <0-35> mcs9 <0-35>",
CS_STR "Set link quality ranges for each uplink MCS\n"
"Set quality range for MCS-1 (high value only)\n"
"MCS-1 high (dB)\n"
"Set quality range for MCS-2\n"
"MCS-2 high (dB)\n"
"MCS-2 low (dB)\n"
"Set quality range for MCS-3\n"
"MCS-3 high (dB)\n"
"MCS-3 low (dB)\n"
"Set quality range for MCS-4\n"
"MCS-4 high (dB)\n"
"MCS-4 low (dB)\n"
"Set quality range for MCS-5\n"
"MCS-5 high (dB)\n"
"MCS-5 low (dB)\n"
"Set quality range for MCS-6\n"
"MCS-6 low (dB)\n"
"MCS-6 high (dB)\n"
"Set quality range for MCS-7\n"
"MCS-7 low (dB)\n"
"MCS-7 high (dB)\n"
"Set quality range for MCS-8\n"
"MCS-8 low (dB)\n"
"MCS-8 high (dB)\n"
"Set quality range for MCS-9 (low value only)\n"
"MCS-9 low (dB)\n",
CMD_ATTR_IMMEDIATE)
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
{
Move (m)cs_lqual_ranges fields from BTS to PCU Change-Id: I39e2fc7e229851610d797c594d84902af6079411
2021-01-14 12:30:04 +00:00
the_pcu->vty.mcs_lqual_ranges[0].high = atoi(argv[0]);
the_pcu->vty.mcs_lqual_ranges[1].low = atoi(argv[1]);
the_pcu->vty.mcs_lqual_ranges[1].high = atoi(argv[2]);
the_pcu->vty.mcs_lqual_ranges[2].low = atoi(argv[3]);
the_pcu->vty.mcs_lqual_ranges[2].high = atoi(argv[4]);
the_pcu->vty.mcs_lqual_ranges[3].low = atoi(argv[5]);
the_pcu->vty.mcs_lqual_ranges[3].high = atoi(argv[6]);
the_pcu->vty.mcs_lqual_ranges[4].low = atoi(argv[7]);
the_pcu->vty.mcs_lqual_ranges[4].high = atoi(argv[8]);
the_pcu->vty.mcs_lqual_ranges[5].low = atoi(argv[9]);
the_pcu->vty.mcs_lqual_ranges[5].high = atoi(argv[10]);
the_pcu->vty.mcs_lqual_ranges[6].low = atoi(argv[11]);
the_pcu->vty.mcs_lqual_ranges[6].high = atoi(argv[12]);
the_pcu->vty.mcs_lqual_ranges[7].low = atoi(argv[13]);
the_pcu->vty.mcs_lqual_ranges[7].high = atoi(argv[14]);
the_pcu->vty.mcs_lqual_ranges[8].low = atoi(argv[15]);
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
return CMD_SUCCESS;
}
Add pcu-socket vty config osmo-bts already supports configuring a different path for the bts<->pcu socket by using the 'pcu-socket' config field. Change-Id: I9b3e1171da467519750b201849ec892a1e318129
2017-08-08 13:03:50 +00:00
DEFUN(cfg_pcu_sock,
cfg_pcu_sock_cmd,
"pcu-socket PATH",
"Configure the osmo-bts PCU socket file/path name\n"
"Path of the socket to connect to\n")
{
VTY: add warning about changing PCU socket path at run-time Change-Id: I7cee2d782bd3dfc2cc8d2febc16dca905dcc294e
2019-11-30 13:13:25 +00:00
if (vty->type != VTY_FILE)
vty_out(vty, "Changing PCU socket path at run-time has no effect%s", VTY_NEWLINE);
Split PCU global PCU object from BTS object Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold both PCU global fields and BTS specific fields, all mangled together. The BTS is even accessed in lots of places by means of a singleton. This patch introduces a new struct gprs_pcu object aimed at holding all global state, and several fields are already moved from BTS to it. The new object can be accessed as global variable "the_pcu", reusing and including an already exisitng "the_pcu" global variable only used for bssgp related purposes so far. This is only a first step towards having a complete split global pcu and BTS, some fields are still kept in BTS and will be moved over follow-up smaller patches in the future (since this patch is already quite big). So far, the code still only supports one BTS, which can be accessed using the_pcu->bts. In the future that field will be replaced with a list, and the BTS singletons will be removed. The cur_fn output changes in TbfTest are actually a side effect fix, since the singleton main_bts() now points internally to the_pcu->bts, hence the same we allocate and assign in the test. Beforehand, "the_bts" was allocated in the stack while main_bts() still returned an unrelated singleton BTS object instance. Related: OS#4935 Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-13 17:54:38 +00:00
osmo_talloc_replace_string(tall_pcu_ctx, &the_pcu->pcu_sock_path, argv[0]);
Add pcu-socket vty config osmo-bts already supports configuring a different path for the bts<->pcu socket by using the 'pcu-socket' config field. Change-Id: I9b3e1171da467519750b201849ec892a1e318129
2017-08-08 13:03:50 +00:00
return CMD_SUCCESS;
}
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_USRATTR(cfg_pcu_gb_dialect,
cfg_pcu_gb_dialect_cmd,
X(PCU_VTY_ATTR_NS_RESET),
"gb-dialect (classic|ip-sns)",
"Select which Gb interface dialect to use\n"
"Classic Gb interface with NS-{RESET,BLOCK,UNBLOCK} and static configuration\n"
"Modern Gb interface with IP-SNS (Sub Network Service) and dynamic configuration\n")
Optionally Use the NS Sub-Network-Service (SNS) on Gb This change add support for the recently-introduced GPRS Gb interface auto-configuration using the NS IP Sub-Network Service (SNS) procedures. It requires a Change-Id I84786c3b43a8ae34ef3b3ba84b33c90042d234ea of libosmocore. Related: OS#3372 Depends: I84786c3b43a8ae34ef3b3ba84b33c90042d234ea (libosmcore) Change-Id: I256b40ac592d3b6e75dd581bf7b9512f69b11e83
2018-07-05 01:11:17 +00:00
{
Use the new NS2 lib Depends: Id7edb8feb96436ba170383fc62d43ceb16955d53 (libosmocore) Depends: I2a9dcd14f4ad16211c0f6d98812ad4a13e910c2a (libosmocore) Change-Id: Ib389925cf5c9f18951af6242c31ea70476218e9a
2020-09-16 19:52:02 +00:00
if (!strcmp(argv[0], "ip-sns")) {
follow gprs_ns2 API enum changes All gprs_ns2 enums have now GPRS_NS2 as prefix. Depends-on: I548ff12f7277cbb7e1a630a3dc02b738ce89be72 (libosmocore) Change-Id: Ifdc7956318c07d680feab33c22bc2c6f20927bf9
2021-01-25 19:28:38 +00:00
the_pcu->vty.ns_dialect = GPRS_NS2_DIALECT_SNS;
Use the new NS2 lib Depends: Id7edb8feb96436ba170383fc62d43ceb16955d53 (libosmocore) Depends: I2a9dcd14f4ad16211c0f6d98812ad4a13e910c2a (libosmocore) Change-Id: Ib389925cf5c9f18951af6242c31ea70476218e9a
2020-09-16 19:52:02 +00:00
} else {
follow gprs_ns2 API enum changes All gprs_ns2 enums have now GPRS_NS2 as prefix. Depends-on: I548ff12f7277cbb7e1a630a3dc02b738ce89be72 (libosmocore) Change-Id: Ifdc7956318c07d680feab33c22bc2c6f20927bf9
2021-01-25 19:28:38 +00:00
the_pcu->vty.ns_dialect = GPRS_NS2_DIALECT_IPACCESS;
Use the new NS2 lib Depends: Id7edb8feb96436ba170383fc62d43ceb16955d53 (libosmocore) Depends: I2a9dcd14f4ad16211c0f6d98812ad4a13e910c2a (libosmocore) Change-Id: Ib389925cf5c9f18951af6242c31ea70476218e9a
2020-09-16 19:52:02 +00:00
}
Optionally Use the NS Sub-Network-Service (SNS) on Gb This change add support for the recently-introduced GPRS Gb interface auto-configuration using the NS IP Sub-Network Service (SNS) procedures. It requires a Change-Id I84786c3b43a8ae34ef3b3ba84b33c90042d234ea of libosmocore. Related: OS#3372 Depends: I84786c3b43a8ae34ef3b3ba84b33c90042d234ea (libosmcore) Change-Id: I256b40ac592d3b6e75dd581bf7b9512f69b11e83
2018-07-05 01:11:17 +00:00
return CMD_SUCCESS;
}
vty: Add configuration for Gb DSCP and socket priority While libosmogb / ns2 supports that natively in the VTY, the PCU doesn't want to use the complexities of the full NS2 vty. Change-Id: I7bfbad46582e65e5ad2ac0cc66545538bc632df8 Related: SYS#5427
2021-04-29 20:02:47 +00:00
DEFUN_USRATTR(cfg_pcu_gb_ip_dscp,
cfg_pcu_gb_ip_dscp_cmd,
X(PCU_VTY_ATTR_NS_RESET),
"gb ip-dscp <0-63>",
"Configure Gb interface\n"
"Set IP DSCP value for outbound packets\n"
"IP DSCP value to use\n")
{
the_pcu->vty.ns_ip_dscp = atoi(argv[0]);
return CMD_SUCCESS;
}
DEFUN_USRATTR(cfg_pcu_gb_priority,
cfg_pcu_gb_priority_cmd,
X(PCU_VTY_ATTR_NS_RESET),
"gb socket-priority <0-255>",
"Configure Gb interface\n"
"Set socket priority value for outbound packets\n"
"Socket priority value to use (>6 requires CAP_NET_ADMIN)")
{
the_pcu->vty.ns_priority = atoi(argv[0]);
return CMD_SUCCESS;
}
Introduce NACC support A new nacc_fsm is introduced per MS object, with its partner priv structure struct nacc_fsm_ctx, which exists and is available in the MS object only during the duration of the NACC procedure. The NACC context is created on an MS whenever a Pkt Cell Change Notification is received on Uplink RLCMAC, which asks for neighbor information of a given ARFCN+BSIC. First, the target ARFCN+BSIC needs to be translated into a CGI-PS (RAC+CI) address. That's done by asking the BSC through the Neighbour Resolution Service available in osmo-bsc using the CTRL interface. Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO request against the SGSN (which will route the request as needed), and wait for a response containing the SI bits from the target cell. After the SI are received, the scheduler is instructed to eventually poll a TBF for the MS originating the CCN, so that we can send the SI encapsulated into multiple Packet Neighbor Cell Data messages on the downlink. One all the SI bits are sent, the scheduler is instructed to send a Packet Cell Change Continue message. Once the message above has been sent, the FSM autodestroys itself. Caches are also introduced in this patch which allows for re-using recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO respectively. Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
2021-01-21 17:46:13 +00:00
DEFUN(cfg_neighbor_resolution, cfg_neighbor_resolution_cmd,
"neighbor resolution " VTY_IPV46_CMD " [<0-65535>]",
"Manage local and remote-BSS neighbor cells\n"
"Connect to Neighbor Resolution Service (CTRL interface) to given ip and port\n"
"IPv4 address to connect to\n" "IPv6 address to connect to\n"
"Port to connect to (default 4248)\n")
{
Support Neighbor Address Resolution over PCUIF IPA multiplex While NACC was initially developed, it became clear there was need for a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS for later RIM usage. Hence, this resolution was first (until today) implemented using an out of bands RPC system using the CTRL interface, which required specific config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port of the CTRL interface to use). However, this has several shortcomings: * As explained above, specific configuration is required * Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS may switch to a BSC other than first one. If that happened, that'd mean the CTRL interface would still point to the initially configured one, which may not be the same currently serving the PCU. During recent development of ANR related features, a similar need for PCU<->BSC was required, but this time it was decided to extend the IPA multiplex of the Abis OML connection to pass PCUIF messages, transparently forwarded to each side by the BTS. This has the advantage that connection PCU<->BTS is handled by BTS and both sides send messages transparently. Let's switch by default to using this new interface, while still maintaing the old way for a while (announcing them as deprecated) to avoid breaking existing deployments until they are upgraded to new versions of osmo-pcu and osmo-bsc. Related: SYS#4971 Change-Id: I6ad33c7ab10202840cf804dea9ba595978d0e920
2021-09-07 12:09:50 +00:00
vty_out(vty, "%% Warning: The CTRL interface for Neighbor Address Resolution is now deprecated."
"Upgrade osmo-bsc and drop the 'neighbor resolution " VTY_IPV46_CMD " [<0-65535>]' VTY "
"option in order to let osmo-pcu use the new resoluton method using the PCUIF over IPA "
"multiplex, which will work out of the box without required configuration.%s", VTY_NEWLINE);
Introduce NACC support A new nacc_fsm is introduced per MS object, with its partner priv structure struct nacc_fsm_ctx, which exists and is available in the MS object only during the duration of the NACC procedure. The NACC context is created on an MS whenever a Pkt Cell Change Notification is received on Uplink RLCMAC, which asks for neighbor information of a given ARFCN+BSIC. First, the target ARFCN+BSIC needs to be translated into a CGI-PS (RAC+CI) address. That's done by asking the BSC through the Neighbour Resolution Service available in osmo-bsc using the CTRL interface. Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO request against the SGSN (which will route the request as needed), and wait for a response containing the SI bits from the target cell. After the SI are received, the scheduler is instructed to eventually poll a TBF for the MS originating the CCN, so that we can send the SI encapsulated into multiple Packet Neighbor Cell Data messages on the downlink. One all the SI bits are sent, the scheduler is instructed to send a Packet Cell Change Continue message. Once the message above has been sent, the FSM autodestroys itself. Caches are also introduced in this patch which allows for re-using recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO respectively. Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
2021-01-21 17:46:13 +00:00
osmo_talloc_replace_string(the_pcu, &the_pcu->vty.neigh_ctrl_addr, argv[0]);
if (argc > 1)
the_pcu->vty.neigh_ctrl_port = atoi(argv[1]);
else
the_pcu->vty.neigh_ctrl_port = OSMO_CTRL_PORT_BSC_NEIGH;
return CMD_SUCCESS;
}
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
DEFUN(show_bts_timer, show_bts_timer_cmd,
"show bts-timer " OSMO_TDEF_VTY_ARG_T_OPTIONAL,
SHOW_STR "Show BTS controlled timers\n"
OSMO_TDEF_VTY_DOC_T)
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
const char *T_arg = argc > 0 ? argv[0] : NULL;
vty_out(vty, "BTS%" PRIu8 ":%s", bts->nr, VTY_NEWLINE);
osmo_tdef_vty_show_cmd(vty, bts->T_defs_bts, T_arg, " ");
}
return CMD_SUCCESS;
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
}
DEFUN(show_timer, show_timer_cmd,
"show timer " OSMO_TDEF_VTY_ARG_T_OPTIONAL,
SHOW_STR "Show PCU timers\n"
OSMO_TDEF_VTY_DOC_T)
{
const char *T_arg = argc > 0 ? argv[0] : NULL;
Move T_defs_pcu from BTS to PCU object Change-Id: I0cac5c12dff2e90b52d00383a00b4b94a9603a0a
2021-01-14 11:01:42 +00:00
return osmo_tdef_vty_show_cmd(vty, the_pcu->T_defs, T_arg, NULL);
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
}
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
DEFUN_ATTR(cfg_pcu_timer, cfg_pcu_timer_cmd,
"timer " OSMO_TDEF_VTY_ARG_SET_OPTIONAL,
"Configure or show PCU timers\n"
OSMO_TDEF_VTY_DOC_SET,
CMD_ATTR_IMMEDIATE)
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
{
NACC: allow setting keep time for entries in neigh and si cache Related: SYS#4909 Change-Id: Ifa336aa27dd88ff5b78dbc5a2799740f542bb369
2021-01-26 16:51:44 +00:00
int rc;
struct osmo_tdef *t;
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
/* If any arguments are missing, redirect to 'show' */
if (argc < 2)
return show_timer(self, vty, argc, argv);
NACC: allow setting keep time for entries in neigh and si cache Related: SYS#4909 Change-Id: Ifa336aa27dd88ff5b78dbc5a2799740f542bb369
2021-01-26 16:51:44 +00:00
if ((rc = osmo_tdef_vty_set_cmd(vty, the_pcu->T_defs, argv)) != CMD_SUCCESS)
return rc;
t = osmo_tdef_vty_parse_T_arg(vty, the_pcu->T_defs, argv[0]);
switch (t->T) {
case PCU_TDEF_NEIGH_CACHE_ALIVE:
neigh_cache_set_keep_time_interval(the_pcu->neigh_cache, t->val);
break;
case PCU_TDEF_SI_CACHE_ALIVE:
si_cache_set_keep_time_interval(the_pcu->si_cache, t->val);
break;
default:
break;
}
return CMD_SUCCESS;
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
}
pcu_vty: Add a command to print info about all TBFs
2014-01-15 16:06:51 +00:00
DEFUN(show_tbf,
show_tbf_cmd,
vty: add commands to show TBF of a certain kind Add vty commands to show only TBFs allocated via PACCH or CCCH. Change-Id: I80f8df4fe663a0346f4289a4220b761e39726312 Related: OS#1759
2018-02-01 15:07:33 +00:00
"show tbf (all|ccch|pacch)",
SHOW_STR "information about TBFs\n"
"All TBFs\n"
"TBFs allocated via CCCH\n"
"TBFs allocated via PACCH\n")
pcu_vty: Add a command to print info about all TBFs
2014-01-15 16:06:51 +00:00
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
uint32_t flags = UINT32_MAX;
vty: add commands to show TBF of a certain kind Add vty commands to show only TBFs allocated via PACCH or CCCH. Change-Id: I80f8df4fe663a0346f4289a4220b761e39726312 Related: OS#1759
2018-02-01 15:07:33 +00:00
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
if (argv[0][0] == 'c')
flags = (1 << GPRS_RLCMAC_FLAG_CCCH);
else if (argv[0][0] == 'p')
flags = (1 << GPRS_RLCMAC_FLAG_PACCH);
vty: add commands to show TBF of a certain kind Add vty commands to show only TBFs allocated via PACCH or CCCH. Change-Id: I80f8df4fe663a0346f4289a4220b761e39726312 Related: OS#1759
2018-02-01 15:07:33 +00:00
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
pcu_vty_show_tbf_all(vty, bts, flags);
}
return CMD_SUCCESS;
pcu_vty: Add a command to print info about all TBFs
2014-01-15 16:06:51 +00:00
}
bts: Start creating statistics inside the BTS code
2013-10-27 08:02:31 +00:00
vty: Add 'show ms all' command This command lists the entries of the ms_store by a line per MS. Beside TLLI and IMSI, some measurement and state information is shown. A ms_list() getter method is added to GprsMsStorage to obtain a list of the MsGprs objects. The following VTY command is added to the 'enable' node: - show ms all Sponsored-by: On-Waves ehf
2015-06-04 08:23:24 +00:00
DEFUN(show_ms_all,
show_ms_all_cmd,
"show ms all",
SHOW_STR "information about MSs\n" "All TBFs\n")
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
pcu_vty_show_ms_all(vty, bts);
}
return CMD_SUCCESS;
vty: Add 'show ms all' command This command lists the entries of the ms_store by a line per MS. Beside TLLI and IMSI, some measurement and state information is shown. A ms_list() getter method is added to GprsMsStorage to obtain a list of the MsGprs objects. The following VTY command is added to the 'enable' node: - show ms all Sponsored-by: On-Waves ehf
2015-06-04 08:23:24 +00:00
}
vty: Add command to show detailed MS info This commit extends the "show ms" command to display an extended set of information for a single MS. The following VTY commands are added: - show ms tlli TLLI - show ms imsi IMSI Sponsored-by: On-Waves ehf
2015-06-05 14:33:33 +00:00
DEFUN(show_ms_tlli,
show_ms_tlli_cmd,
"show ms tlli TLLI",
SHOW_STR "information about MSs\n" "Select MS by TLLI\n" "TLLI as hex\n")
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
char *endp = NULL;
unsigned long long tlli = strtoll(argv[0], &endp, 16);
if ((endp != NULL && *endp != 0) || tlli > 0xffffffffULL) {
vty_out(vty, "Invalid TLLI.%s", VTY_NEWLINE);
return CMD_WARNING;
}
pcu_vty_show_ms_by_tlli(vty, bts, (uint32_t)tlli);
vty: Add command to show detailed MS info This commit extends the "show ms" command to display an extended set of information for a single MS. The following VTY commands are added: - show ms tlli TLLI - show ms imsi IMSI Sponsored-by: On-Waves ehf
2015-06-05 14:33:33 +00:00
}
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
return CMD_SUCCESS;
vty: Add command to show detailed MS info This commit extends the "show ms" command to display an extended set of information for a single MS. The following VTY commands are added: - show ms tlli TLLI - show ms imsi IMSI Sponsored-by: On-Waves ehf
2015-06-05 14:33:33 +00:00
}
DEFUN(show_ms_imsi,
show_ms_imsi_cmd,
"show ms imsi IMSI",
SHOW_STR "information about MSs\n" "Select MS by IMSI\n" "IMSI\n")
{
Allow multiple bts objects in PCU This patch doesn't really tests whether osmo-pcu can work on a multi-bts environment, but it prepares the data structures to be able to do so at any later point in time. Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
2021-01-18 16:14:14 +00:00
struct gprs_rlcmac_bts *bts;
llist_for_each_entry(bts, &the_pcu->bts_list, list) {
pcu_vty_show_ms_by_imsi(vty, bts, argv[0]);
}
return CMD_SUCCESS;
vty: Add command to show detailed MS info This commit extends the "show ms" command to display an extended set of information for a single MS. The following VTY commands are added: - show ms tlli TLLI - show ms imsi IMSI Sponsored-by: On-Waves ehf
2015-06-05 14:33:33 +00:00
}
VTY implementation
2012-07-12 12:31:57 +00:00
static const char pcu_copyright[] =
VTY: complete the copyright message
2013-01-17 11:24:29 +00:00
"Copyright (C) 2012 by Ivan Kluchnikov <kluchnikovi@gmail.com> and \r\n"
" Andreas Eversberg <jolly@eversberg.eu>\r\n"
VTY implementation
2012-07-12 12:31:57 +00:00
"License GNU GPL version 2 or later\r\n"
"This is free software: you are free to change and redistribute it.\r\n"
"There is NO WARRANTY, to the extent permitted by law.\r\n";
struct vty_app_info pcu_vty_info = {
Remove dash from name used in VTY cmd prompt Others projects don't contain a dash in there, and it seems to cause problems with TTCN3 VTY expectations. Change-Id: I3430abb5fc622dec293457466e760de95fa3a05c
2019-11-29 12:37:45 +00:00
.name = "OsmoPCU",
VTY implementation
2012-07-12 12:31:57 +00:00
.version = PACKAGE_VERSION,
.copyright = pcu_copyright,
vty: add attributes to VTY commands indicating when they apply Change-Id: I63978ce3ea87593c9a41e503ed3b761c64e1e80f Related: SYS#4937, OS#1601
2020-09-29 21:31:33 +00:00
.usr_attr_desc = {
[PCU_VTY_ATTR_NEW_TBF] = \
"This command applies when a new TBF is begins",
[PCU_VTY_ATTR_NEW_SUBSCR] = \
"This command applies when a new subscriber attaches",
[PCU_VTY_ATTR_NS_RESET] = \
"This command applies when the NS is reset",
},
.usr_attr_letters = {
[PCU_VTY_ATTR_NEW_TBF] = 'n',
[PCU_VTY_ATTR_NEW_SUBSCR] = 's',
[PCU_VTY_ATTR_NS_RESET] = 'r',
},
VTY implementation
2012-07-12 12:31:57 +00:00
};
Remove undefined param passed to {logging,osmo_stats}_vty_add_cmds Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. API osmo_stats_vty_add_cmds never had a param list but has seem problem (no "void"), so some users decided to pass a parameter to it. Related: OS#4138 Change-Id: Ic1ac815eafab49577ff883a5d700ecca5936d216
2019-08-05 12:30:44 +00:00
int pcu_vty_init(void)
VTY implementation
2012-07-12 12:31:57 +00:00
{
// install_element_ve(&show_pcu_cmd);
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
cfg_pcu_gsmtap_categ_cmd.string = vty_cmd_string_from_valstr(tall_pcu_ctx, pcu_gsmtap_categ_names,
"gsmtap-category (",
"|",")", VTY_DO_LOWER);
cfg_pcu_gsmtap_categ_cmd.doc = vty_cmd_string_from_valstr(tall_pcu_ctx, pcu_gsmtap_categ_help,
"GSMTAP Category\n",
"\n", "", 0);
cfg_pcu_no_gsmtap_categ_cmd.string = vty_cmd_string_from_valstr(tall_pcu_ctx, pcu_gsmtap_categ_names,
"no gsmtap-category (",
"|",")", VTY_DO_LOWER);
cfg_pcu_no_gsmtap_categ_cmd.doc = vty_cmd_string_from_valstr(tall_pcu_ctx, pcu_gsmtap_categ_help,
NO_STR "GSMTAP Category\n",
"\n", "", 0);
Remove undefined param passed to {logging,osmo_stats}_vty_add_cmds Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. API osmo_stats_vty_add_cmds never had a param list but has seem problem (no "void"), so some users decided to pass a parameter to it. Related: OS#4138 Change-Id: Ic1ac815eafab49577ff883a5d700ecca5936d216
2019-08-05 12:30:44 +00:00
logging_vty_add_cmds();
osmo_stats_vty_add_cmds();
VTY: install talloc context introspection commands Change-Id: I2e1e26be1162b0fb695969e5ac265704adaf9d5c
2020-02-06 09:46:17 +00:00
osmo_talloc_vty_add_cmds();
vty: register libosmocore's FSM introspection commands Change-Id: Id268e44de6eb873138f38720a61cabe589a5d2c8
2021-02-05 22:22:37 +00:00
osmo_fsm_vty_add_cmds();
VTY implementation
2012-07-12 12:31:57 +00:00
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
install_node(&pcu_node, config_write_pcu);
install_element(CONFIG_NODE, &cfg_pcu_cmd);
edge: Add egprs config command Add a global config flag to enable the use EDGE/EGPRS. The following VTY commands are added to node config-pcu: - egprs Enables EGPRS - no egprs Disable EGPRS Note that enabling EGPRS is experimental and will most likely break packet transmission until a minimal required set of EGPRS functionality is implemented. Sponsored-by: On-Waves ehf
2015-09-28 16:12:57 +00:00
install_element(PCU_NODE, &cfg_pcu_egprs_cmd);
install_element(PCU_NODE, &cfg_pcu_no_egprs_cmd);
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
install_element(PCU_NODE, &cfg_pcu_no_two_phase_cmd);
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
install_element(PCU_NODE, &cfg_pcu_cs_cmd);
install_element(PCU_NODE, &cfg_pcu_no_cs_cmd);
ms: Add support for maximum CS values Currently the CS values can be increased to CS4 even when the "cs" configuration command has been used with a lower value. The "cs" command just sets the initial coding scheme, so other means are needed to limit the selection. One approach is to use the CS flags passed in SI, but these are currently ignored. To make it possible to limit the CS selection by configuring the PCU, this commit adds the following VTY commands to config-pcu: - cs max <1-4> Limit DL and UL CS to the given value - cs max <1-4> <1-4> Limit DL and UL CS separately (DL first) - no cs max Don't limit Ticket: #1674 Sponsored-by: On-Waves ehf
2015-06-04 17:04:30 +00:00
install_element(PCU_NODE, &cfg_pcu_cs_max_cmd);
install_element(PCU_NODE, &cfg_pcu_no_cs_max_cmd);
tbf: Add adaptive coding scheme configuration This commit adds the following VTY commands to config-pcu: - cs threshold <0-100> <0-100> Enables adaptive CS selection - no cs threshold Disables it The "cs threshold LOW HIGH" command sets the water marks (cs_adj_lower_limit and cs_adj_upper_limit) used to decide about switching coding schemes. Ticket: #1739 Sponsored-by: On-Waves ehf
2015-06-04 13:12:10 +00:00
install_element(PCU_NODE, &cfg_pcu_cs_err_limits_cmd);
install_element(PCU_NODE, &cfg_pcu_no_cs_err_limits_cmd);
ms: Reduce DL CS level if only a few LLC bytes are left If just a few bytes are left to send to the MS, it makes sense to reduce the coding scheme level to increase the throughput. This has been shown by Chen and Goodman in their paper "Theoretical Analysis of GPRS Throughput and Delay". See their throughput over C/I measurement graphs (figures 4 and 5 in the paper) for details. This commit implements a simplified CS downgrade feature for the downlink. The coding scheme will be downgraded if there are only a few octets are left to be send over the TBF (see the downgrade-threshold command below) and the NACK rate is not low (the CS will not get degraded on a high quality RF link). As an exception, CS-3 will be degraded to CS-1, since CS-2 does not improve the throughput in general when a few small packets are sent and the signal fades slowly (see Chen/Goodman). The following VTY command is added to the config-pcu node: - cs downgrade-threshold <1-10000> - cs no downgrade-threshold to set the threshold of the number of remaining bytes to be RLC/MAC encoded. The CS will only be reduced, if the number is below the threshold. The 'no' command disables this feature completely. The default value is 200 octets. Sponsored-by: On-Waves ehf
2015-06-12 08:52:34 +00:00
install_element(PCU_NODE, &cfg_pcu_cs_downgrade_thrsh_cmd);
install_element(PCU_NODE, &cfg_pcu_no_cs_downgrade_thrsh_cmd);
ms: Add UL CS selection based on L1 link quality Currently the UL CS values are set to the corresponding DL CS value, eventually limited by a maximum value. This approach does not reflect the general situation of the RF link between ME and BTS, which is rather asymmetric e.g. due to a lower degree of TX efficiency of the built-in antenna. This means, that UL and DL CS control should be decoupled for better results. This commit adds automatic UL CS selection based on the link quality measurement parameter. Each coding scheme is mapped to a link quality range. If the link quality value leaves that range, the current UL CS value is increased/decreased accordingly. This value will be copied when the next PACKET_UPLINK_ACK_NACK or PACKET_UPLINK_ASSIGMENT is sent to the MS. The following VTY command will be added to the config-pcu node: - cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35> which sets the ranges for the four coding schemes. For instance the example below reflects the current default values: cs link-quality-ranges cs1 6 cs2 5 8 cs3 7 13 cs4 12 set the following ranges, where the overlapping is used to configure a hysteresis: CS1: -inf .. 6 CS2: 5 .. 8 CS3: 7 .. 13 CS4: 12 .. inf Sponsored-by: On-Waves ehf
2015-06-09 07:44:36 +00:00
install_element(PCU_NODE, &cfg_pcu_cs_lqual_ranges_cmd);
EDGE: Fix UL link adaptation. We have seen that UL MCS5- MCS9 link adaptation has not been implemented in current PCU implementation. If the MS slowly moves far away from the BTS, the UL MCS will always stick at MCS9 no matter UL link quality values leading to poor data service experience. The UL MCS is expected to adapt from MCS9 -> MCSx due to bad UL quality. Below PCU traces indicate that UL MCS is quickly increasing to MCS9 (max MCS 9 was used in this test) and it never changes to other UL MCS due zero thresholds. <0004> gprs_ms.cpp:670 MS (IMSI ): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-6 -> MCS-7 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-7 -> MCS-8 <0004> gprs_ms.cpp:670 MS (IMSI 000): Link quality 23dB (23dB) left window [0, 0], modifying uplink CS level: MCS-8 -> MCS-9 Change-Id: I9272c337ad6399da4a47cc6e2736e25f24e099d8
2017-08-16 13:50:06 +00:00
install_element(PCU_NODE, &cfg_pcu_mcs_lqual_ranges_cmd);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
install_element(PCU_NODE, &cfg_pcu_mcs_cmd);
Modify EGPRS DL TBF flow to support SPB Modify the EGPRS DL TBF flow to support Split block during Retx. This patch will also Upgrade the test suite with test cases to validate the EGPRS Downlink SPB for Retransmission Scenarios like MCS6->MCS3, MCS4->MCS1, MCS5->MCS2, MCS9->MCS3 MCS7->MCS2, MCS8->MCS3 have been simulated and Integration tested in NuRAN 1.0 hardware thoroughly. Change-Id: I242afdd8ae7622dec8593b26382ad66bad5b9516
2016-08-22 11:51:10 +00:00
install_element(PCU_NODE, &cfg_pcu_dl_arq_cmd);
edge/vty: Set initial MCS This adds the following VTY command (config-pcu node): - mcs <1-9> sets initial DL and UL MCS to the same value - mcs <1-9> <1-9> sets initial DL and UL MCS separately - no mcs sets the default values Sponsored-by: On-Waves ehf
2016-02-02 15:02:16 +00:00
install_element(PCU_NODE, &cfg_pcu_no_mcs_cmd);
edge: Add max_mcs_ul and max_mcs_dl config This sets the maximum MCS encoding used for EGPRS RLC data blocks in either direction. The following VTY command are added to node config-pcu: - mcs max <1-9> set maximum for both, uplink and downlink - mcs max <1-9> <1-9> set maximum for downlink and uplink (in that order) - no mcs max do not limit Note that using a value of 4 or below for each direction implies that a GMSK-only TBF may be assumed, which for instance would allow the use of the GPRS MS class instead of the possibly more restrictive EGPRS MS class. Sponsored-by: On-Waves ehf
2016-01-07 10:48:28 +00:00
install_element(PCU_NODE, &cfg_pcu_mcs_max_cmd);
install_element(PCU_NODE, &cfg_pcu_no_mcs_max_cmd);
edge: Make window size configurable Currently the window size is fixed to 64 even for EGPRS. Support dynamic window sizes depending on the number of PDCH. The WS can be set to b + f * N_PDCH. If the result is not valid according to TS 44.060, Table 9.1.9.2.1, the value will be corrected to use the next lower valid value (or 64). The following VTY commands are added (config-pcu node): window-size <0-1024> set base (b) value and leave f unchanged window-size <0-1024> <0-256> set base (b) and factor (f) Sponsored-by: On-Waves ehf
2016-01-19 14:53:30 +00:00
install_element(PCU_NODE, &cfg_pcu_window_size_cmd);
Add check of lifetime of LLC frame If lifetime expires of queued LLC frames, they are discarded. The number of discarded frames and the sum of their octets are reported to SGSN via LLC-DISCARDED message. The lifetime can be overridden via VTY. The value can be centi-seconds or "infinite".
2012-07-21 09:09:58 +00:00
install_element(PCU_NODE, &cfg_pcu_queue_lifetime_cmd);
install_element(PCU_NODE, &cfg_pcu_queue_lifetime_inf_cmd);
install_element(PCU_NODE, &cfg_pcu_no_queue_lifetime_cmd);
tbf: Use a hysteresis when discarding DL LLC frames Currently single LLC blocks are discarded when the PDU lifetime expires. If an IP packet has been fragmented either on the IP or on the LLC layer and is therefore distributed over several LLC frames, the kept fragments are transmitted and then discarded by the MS because of the missing PDU. This can cause massive IP packet loss when there are many fragmented packets (e.g. when trying 'ping -s1800' or if the GGSN chops downlink IP packets into several SNDCP packets). On the other hand, discarding too many packets might disturb the congestion handling of TCP. Dropping plain TCP ACKs might also hinder flow control and congestion avoidance. This commit adds a hysteresis algorithm to the LLC discard loop. If an LLC message's age reaches the high water mark, further message's with an age above the low water mark are discarded, too. This is aborted, if a GMM, a non-UI, or a small message is detected. In these cases, that message is kept. The following VTY commands are added (pcu config node): - queue hysteresis <1-65535> set the difference between high (lifetime) and low watermark in centiseconds - no queue hysteresis disable this feature (default) Since the SGSN will most probably send all fragments of a single N-PDU without much delay between them, a value slightly above the average transmission delay jitter between SGSN and PCU is probably a sensible value to discard all fragments of a single IP packet. This is an experimental feature that might be replaced by more advanced means of active queue management in the future. Sponsored-by: On-Waves ehf
2015-03-20 11:02:42 +00:00
install_element(PCU_NODE, &cfg_pcu_queue_hysteresis_cmd);
install_element(PCU_NODE, &cfg_pcu_no_queue_hysteresis_cmd);
llc: Use CoDel to drop packages from the LLC queue Currently packets are only dropped if they have reached their maximum life time. This leads to LLC queues being constantly filled under load, increasing the latency up to the maximum life time. This kind of bufferbloat hinders TCP's congestion avoidance algorithms. To keep the queues short, the CoDel active queue management algorithm can be used. This commit changes to llc_dequeue method to apply the CoDel algorithm to selectively drop LLC frames before they passed to the TBF layer to be encoded in BSNs. This feature is currently disabled by default. The CoDel state is managed per MS since the LLC queues are also kept in the MS objects. Note that there is still some buffering in the TBF objects, in the worst case (CS4) 3.5kByte + LLC-MTU octets are stored there. The resulting additional packet delay is not (yet) taken into account for CoDel. Also note that configuration changes are applied to new MS objects only. The following VTY commands are added to the 'pcu' node: - queue codel activates CoDel, the interval is selected by the implementation - queue codel interval <1-1000> activates CoDel with a fixed interval given in centiseconds (10ms-10s) - no queue codel deactivates CoDel Which interval value to use is still an open issue. For high speed links (e.g. Ethernet), CoDel suggests 100ms. For slower links, the expected RTT is recommended. The current implementation uses a default value of 2000ms. Measurements: Note that the following measurements depend on several other factors, most notably the interaction with the SGSN's flow control. They are just examples to give an idea how CoDel might influence some parameters. The measurements have been done with a single E71, first with a running ping only (Idle), then with an additional TCP download of a 360k file (Busy). The CoDel interval was set to 1s. - Idle : ping ~400ms, avg queue delay 0ms, dropped 0 - Busy, No CoDel: ping ~6s, avg queue delay 4-6s, dropped 0, scheduled 948, duration 54s - Busy, CoDel: ping 500-1500ms, avg queue delay ~600ms, dropped 77, scheduled 1040, duration 60s More measurements with two MS downloading in parallel (two independant measurements per case). - Busy, No CoDel: dropped 0, scheduled 1883, duration 121s dropped 19, scheduled 2003, duration 133s - Busy, CoDel: dropped 22, scheduled 1926, duration 116s dropped 22, scheduled 1955, duration 108s Sponsored-by: On-Waves ehf
2015-07-17 14:39:09 +00:00
install_element(PCU_NODE, &cfg_pcu_queue_codel_cmd);
install_element(PCU_NODE, &cfg_pcu_queue_codel_interval_cmd);
install_element(PCU_NODE, &cfg_pcu_no_queue_codel_cmd);
tbf: Force ACK after the last DL LCC frame has been received If the protocol layers above LLC (e.g. TCP) need an acknowledgement to continue, it can take up to 400ms (single TS) until the MS is polled for Ack/Nack which it can use to request an uplink TBF quickly. The 400ms result from requesting an DL Ack/Nack every 20 RLC blocks until all pending LLC frames have been sent. Especially TCP's slow start mechanism can lead to a high delay at the start of the connection, since the sender will eventually stop after having sent the first packets (up to 4 (RFC2581) or 10 (RFC6928)). This commit modifies append_data() to (re-)start a timer every time it handles an LLC packet and to request an Ack/Nack every time it expires. So if the server ceases to send IP packets, the MS is polled in the assumption, that the server is waiting for an ACK. The following VTY commands are added (pcu node): - queue idle-ack-delay <1-65535> timeout in centiseconds - no queue idle-ack-delay disable this feature (default) A sensible value is 10 (100ms) that at gave promising results when testing locally. Sponsored-by: On-Waves ehf
2015-04-02 11:58:09 +00:00
install_element(PCU_NODE, &cfg_pcu_queue_idle_ack_delay_cmd);
install_element(PCU_NODE, &cfg_pcu_no_queue_idle_ack_delay_cmd);
VTY: Select timeslot allocation algorithm via VTY The selections are: single slot or multislot
2012-07-22 06:58:09 +00:00
install_element(PCU_NODE, &cfg_pcu_alloc_cmd);
Adding single block allocation It is mandatory to support it because MS may request a single block. In this case the network must assign a single block. It is possible to force single block allocation for all uplink requests on RACH. (VTY option)
2012-08-07 14:00:56 +00:00
install_element(PCU_NODE, &cfg_pcu_two_phase_cmd);
Statefull reset and unblock BVCs and sending flow control messages The flow control interval can be set via VTY.
2012-09-23 04:41:21 +00:00
install_element(PCU_NODE, &cfg_pcu_fc_interval_cmd);
bssgp: Add VTY command to Limit the bucket size by time Currently the bucket size is by default being computed based on the leak rate and the expected life time of LLC frames. The latter is either taken from 'queue lifetime' (if given) or a fixed value is used. Using 'queue lifetime' has the drawback that it sets a 'hard' limit, since frames will be dropped if they stay in the queue for a longer time. This commit adds a VTY command to specifically set the time used for the computation of the bucket size advertised to the SGSN. It does not affect the PCUs queue handling in any way. If the bucket time is not set (or if the 'no' command has been used), the old behaviour (see above) is applied. The following VTY commands are added (config-pcu node): - flow-control bucket-time <1-65534> Sets the time in centisecs - no flow-control bucket-time Don't use this time Ticket: OW#1432 Sponsored-by: On-Waves ehf
2015-05-06 08:47:30 +00:00
install_element(PCU_NODE, &cfg_pcu_fc_bucket_time_cmd);
install_element(PCU_NODE, &cfg_pcu_no_fc_bucket_time_cmd);
bssgp: Make BVC bucket size / leak rate configurable Currently the FLOW-CONTROL_BVC message contains fixed values: The tag is 1, the BVC bucket size is 6MB, the BVC bucket leak rate is 820kbit/s, the MS bucket size is 50kB, and the MS leak rate is 50kbit/s. This commit makes the BVC parameters configurable and adds the following VTY commands: - flow-control force-bvc-bucket-size <1-6553500> - no flow-control force-bvc-bucket-size - flow-control force-bvc-leak-rate <1-6553500> - no flow-control force-bvc-leak-rate - flow-control force-ms-bucket-size <1-6553500> - no flow-control force-ms-bucket-size - flow-control force-ms-leak-rate <1-6553500> - no flow-control force-ms-leak-rate The 'no' variants restore the default behaviour. Sponsored-by: On-Waves ehf
2015-04-21 10:56:48 +00:00
install_element(PCU_NODE, &cfg_pcu_fc_bvc_bucket_size_cmd);
install_element(PCU_NODE, &cfg_pcu_no_fc_bvc_bucket_size_cmd);
install_element(PCU_NODE, &cfg_pcu_fc_bvc_leak_rate_cmd);
install_element(PCU_NODE, &cfg_pcu_no_fc_bvc_leak_rate_cmd);
install_element(PCU_NODE, &cfg_pcu_fc_ms_bucket_size_cmd);
install_element(PCU_NODE, &cfg_pcu_no_fc_ms_bucket_size_cmd);
install_element(PCU_NODE, &cfg_pcu_fc_ms_leak_rate_cmd);
install_element(PCU_NODE, &cfg_pcu_no_fc_ms_leak_rate_cmd);
Set Alpha and Gamma at assingment messages for power control The initial power control value Alpha must be set in SI13.
2012-09-27 07:20:45 +00:00
install_element(PCU_NODE, &cfg_pcu_alpha_cmd);
install_element(PCU_NODE, &cfg_pcu_gamma_cmd);
tbf: Implement delayed release of a downlink TBF Currently a DL TBF is immediately closed, when the LLC queue is drained. This will lead to a new DL assignment if data is received afterwards. In addition, it is not possible to keep the PACCH open to poll the MS for UL establishment requests there. GSM 44.060, 9.3.1a suggests to delay the release of an inactive TBF for some time (max 5s). This commit mainly changes create_new_bsn() to send LLC dummy commands as filler if no LLC data is available until keep_open() returns false. The keep_open() functions returns true unless a configurable time has passed after the LLC data store drained. By default, that time is not set which causes keep_open() to always return false, so that delayed release is effectively disabled. The following VTY commands are added: - dl-tbf-idle-time <1-5000> to set the delay in ms - no dl-tbf-idle-time to disable delayed release Ticket: #556 Sponsored-by: On-Waves ehf
2015-03-19 10:22:38 +00:00
install_element(PCU_NODE, &cfg_pcu_dl_tbf_idle_time_cmd);
install_element(PCU_NODE, &cfg_pcu_no_dl_tbf_idle_time_cmd);
tbf_dl: make preemptive retransmission optional Since [1], OsmoPCU already starts to retransmit downlink blocks before the MS has had a chance to receive them and/or send the related acknowledgement in uplink. Make this optional with the new VTY option "no dl-tbf-preemptive-retransmission". [1] e25b5b91f60f20f61096bc6199a05b58ee6c6328 ("tbf: Only create dummy frames if necessary") Related: OS#2408 Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
2019-09-05 13:12:20 +00:00
install_element(PCU_NODE, &cfg_pcu_dl_tbf_preemptive_retransmission_cmd);
install_element(PCU_NODE, &cfg_pcu_no_dl_tbf_preemptive_retransmission_cmd);
tbf: Set MS timeout This commit sets the MS timeout when the MS object is created. The value is taken from the ms_idle_sec field in gprs_rlcmac_bts which can be changed by the VTY commands shown below. The following VTY commands are added to the config-pcu node: - ms-idle-time <1-7200> Set the timeout in seconds - no ms-idle-time Disable the timeout Another timer that is related is T3314 (Ready Timer, default 44s, GSM 24.008, 11.2.2) which requires the SGSN to use paging after its expiry. Longer timeouts can help if adaptive coding scheme selection is used (not yet implemented). On the other hand, measurement values (TA, signal quality) can get invalid after some time, especially with a moving MS. So a value slightly above T3314 is probably a good value to start with. Sponsored-by: On-Waves ehf
2015-05-28 14:11:19 +00:00
install_element(PCU_NODE, &cfg_pcu_ms_idle_time_cmd);
install_element(PCU_NODE, &cfg_pcu_no_ms_idle_time_cmd);
Introduce GSMTAP categories When looking at GSMTAP output so far, one is easily overwhelmed by way too much information being presented. A lot of is consists of DUMMY frames, which are probably of lowest interest, ever. A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by which the user can configure which particular categories (uplink or downlink control or data, gprs or egprs, ...) he actually wants to see in his logs. Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
2017-07-21 19:56:23 +00:00
install_element(PCU_NODE, &cfg_pcu_gsmtap_categ_cmd);
install_element(PCU_NODE, &cfg_pcu_no_gsmtap_categ_cmd);
Add pcu-socket vty config osmo-bts already supports configuring a different path for the bts<->pcu socket by using the 'pcu-socket' config field. Change-Id: I9b3e1171da467519750b201849ec892a1e318129
2017-08-08 13:03:50 +00:00
install_element(PCU_NODE, &cfg_pcu_sock_cmd);
Optionally Use the NS Sub-Network-Service (SNS) on Gb This change add support for the recently-introduced GPRS Gb interface auto-configuration using the NS IP Sub-Network Service (SNS) procedures. It requires a Change-Id I84786c3b43a8ae34ef3b3ba84b33c90042d234ea of libosmocore. Related: OS#3372 Depends: I84786c3b43a8ae34ef3b3ba84b33c90042d234ea (libosmcore) Change-Id: I256b40ac592d3b6e75dd581bf7b9512f69b11e83
2018-07-05 01:11:17 +00:00
install_element(PCU_NODE, &cfg_pcu_gb_dialect_cmd);
vty: Add configuration for Gb DSCP and socket priority While libosmogb / ns2 supports that natively in the VTY, the PCU doesn't want to use the complexities of the full NS2 vty. Change-Id: I7bfbad46582e65e5ad2ac0cc66545538bc632df8 Related: SYS#5427
2021-04-29 20:02:47 +00:00
install_element(PCU_NODE, &cfg_pcu_gb_ip_dscp_cmd);
install_element(PCU_NODE, &cfg_pcu_gb_priority_cmd);
Introduce NACC support A new nacc_fsm is introduced per MS object, with its partner priv structure struct nacc_fsm_ctx, which exists and is available in the MS object only during the duration of the NACC procedure. The NACC context is created on an MS whenever a Pkt Cell Change Notification is received on Uplink RLCMAC, which asks for neighbor information of a given ARFCN+BSIC. First, the target ARFCN+BSIC needs to be translated into a CGI-PS (RAC+CI) address. That's done by asking the BSC through the Neighbour Resolution Service available in osmo-bsc using the CTRL interface. Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO request against the SGSN (which will route the request as needed), and wait for a response containing the SI bits from the target cell. After the SI are received, the scheduler is instructed to eventually poll a TBF for the MS originating the CCN, so that we can send the SI encapsulated into multiple Packet Neighbor Cell Data messages on the downlink. One all the SI bits are sent, the scheduler is instructed to send a Packet Cell Change Continue message. Once the message above has been sent, the FSM autodestroys itself. Caches are also introduced in this patch which allows for re-using recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO respectively. Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
2021-01-21 17:46:13 +00:00
install_element(PCU_NODE, &cfg_neighbor_resolution_cmd);
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
install_element(PCU_NODE, &cfg_pcu_timer_cmd);
VTY: Added option to force given CS and ignore the scheme given by BTS
2012-07-20 19:50:31 +00:00
bts: Start creating statistics inside the BTS code
2013-10-27 08:02:31 +00:00
install_element_ve(&show_bts_stats_cmd);
vty: Add 'show bts pdch' command This allows to see which channels have been enabled according to PCU. Change-Id: If72e67ba80aab4e0c68408e6996d74d2ff70c322
2020-09-22 15:01:31 +00:00
install_element_ve(&show_bts_pdch_cmd);
pcu_vty: Add a command to print info about all TBFs
2014-01-15 16:06:51 +00:00
install_element_ve(&show_tbf_cmd);
vty: Add 'show ms all' command This command lists the entries of the ms_store by a line per MS. Beside TLLI and IMSI, some measurement and state information is shown. A ms_list() getter method is added to GprsMsStorage to obtain a list of the MsGprs objects. The following VTY command is added to the 'enable' node: - show ms all Sponsored-by: On-Waves ehf
2015-06-04 08:23:24 +00:00
install_element_ve(&show_ms_all_cmd);
vty: Add command to show detailed MS info This commit extends the "show ms" command to display an extended set of information for a single MS. The following VTY commands are added: - show ms tlli TLLI - show ms imsi IMSI Sponsored-by: On-Waves ehf
2015-06-05 14:33:33 +00:00
install_element_ve(&show_ms_tlli_cmd);
install_element_ve(&show_ms_imsi_cmd);
Introduce osmo_tdef infra and timer VTY commands This will allow for configuration of some of the timers by the user, and allow him to inspect current values being used. It will be also useful for TTCN3 tests which may want to test some of the timers without having to wait for lots of time. Timers are splitted into 2 groups: BTS controlled ones and PCU controlled ones. The BTS controlled ones are read-only by the user (hence no "timer" VTY command is provided to change them). TbfTest.err output changes due to timers being set up correctly as a consequence of changes. Other application such as pcu_emu.cpp and pcu_main.cpp had to previosuly set the initial values by hand (and did so), but apparently TbfTest.c was missing that part, which is now fixed for free. Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
2019-09-05 12:48:35 +00:00
install_element_ve(&show_bts_timer_cmd);
install_element_ve(&show_timer_cmd);
bts: Start creating statistics inside the BTS code
2013-10-27 08:02:31 +00:00
VTY implementation
2012-07-12 12:31:57 +00:00
return 0;
}