osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

6 participants
480 discussions

by Aravind Sirsikar

Enables user to Enable/Disable FANR feature from VTY interface This is second patch among series of patches for FANR feature --- src/bts.h | 1 + src/pcu_main.cpp | 4 ++++ src/pcu_vty.c | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+) diff --git a/src/bts.h b/src/bts.h index ccb8025..7e3ea80 100644 --- a/src/bts.h +++ b/src/bts.h @@ -192,6 +192,7 @@ struct gprs_rlcmac_bts { uint8_t force_two_phase; uint8_t alpha, gamma; uint8_t egprs_enabled; + uint8_t fanr_enabled; uint8_t initial_mcs_dl; uint8_t initial_mcs_ul; uint8_t max_mcs_dl; diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp index 9f38742..32d234d 100644 --- a/src/pcu_main.cpp +++ b/src/pcu_main.cpp @@ -183,6 +183,10 @@ int main(int argc, char *argv[]) bts->initial_mcs_ul = 1; bts->max_mcs_ul = 9; bts->max_mcs_dl = 9; + + bts->egprs_enabled = true; + bts->fanr_enabled = false; + /* CS-1 to CS-4 */ bts->cs_lqual_ranges[0].low = -256; bts->cs_lqual_ranges[0].high = 6; diff --git a/src/pcu_vty.c b/src/pcu_vty.c index edc777d..90c828b 100644 --- a/src/pcu_vty.c +++ b/src/pcu_vty.c @@ -59,6 +59,11 @@ static int config_write_pcu(struct vty *vty) else vty_out(vty, " no egprs%s", VTY_NEWLINE); + if (bts->fanr_enabled) + vty_out(vty, " egprs fanr %s", VTY_NEWLINE); + else + vty_out(vty, " no egprs fanr%s", VTY_NEWLINE); + vty_out(vty, " flow-control-interval %d%s", bts->fc_interval, VTY_NEWLINE); if (bts->fc_bvc_bucket_size) @@ -201,6 +206,34 @@ DEFUN(cfg_pcu_no_egprs, return CMD_SUCCESS; } +#define EGPRS_FANR_STR "EGPRS FANR configuration\n" + +DEFUN(cfg_pcu_egprs_fanr, + cfg_pcu_egprs_fanr_cmd, + "egprs_fanr", + EGPRS_FANR_STR) +{ + struct gprs_rlcmac_bts *bts = bts_main_data(); + + bts->fanr_enabled = 1; + vty_out(vty, "%%EGPRS FANR is enabled %s", VTY_NEWLINE); + + return CMD_SUCCESS; +} + +DEFUN(cfg_pcu_no_egprs_fanr, + cfg_pcu_no_egprs_fanr_cmd, + "no egprs fanr", + NO_STR EGPRS_FANR_STR) +{ + struct gprs_rlcmac_bts *bts = bts_main_data(); + + bts->fanr_enabled = 0; + vty_out(vty, "%%EGPRS FANR is disabled %s", VTY_NEWLINE); + + return CMD_SUCCESS; +} + DEFUN(cfg_pcu_fc_interval, cfg_pcu_fc_interval_cmd, "flow-control-interval <1-10>", @@ -929,6 +962,8 @@ int pcu_vty_init(const struct log_info *cat) vty_install_default(PCU_NODE); install_element(PCU_NODE, &cfg_pcu_egprs_cmd); install_element(PCU_NODE, &cfg_pcu_no_egprs_cmd); + install_element(PCU_NODE, &cfg_pcu_egprs_fanr_cmd); + install_element(PCU_NODE, &cfg_pcu_no_egprs_fanr_cmd); install_element(PCU_NODE, &cfg_pcu_no_two_phase_cmd); install_element(PCU_NODE, &cfg_pcu_cs_cmd); install_element(PCU_NODE, &cfg_pcu_no_cs_cmd); -- 1.7.9.5

9 years, 3 months

[PATCH] Fix encoding of padding bits to start with 0 bit

by Saurabh Sharan

This patch is for fixing encoding of padding bits according to the 3gpp spec 44.060 section 11, wherein it shall always start with 0 bit followed with spare padding bits. During introduction of basic EGPRS feature new hex dump messages from a different working network log were used in Unit test. These exposed the issue of incorrect handling of padding bits encoding in osmo-pcu. Corrections in the existing test vector and new hex dump vectors shall be submitted in a separate patch. If only this patch is applied rlcmac testsuite will fail for few vectors. --- src/csn1.cpp | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/csn1.cpp b/src/csn1.cpp index 54cc411..82bf17f 100644 --- a/src/csn1.cpp +++ b/src/csn1.cpp @@ -2400,7 +2400,12 @@ gint16 csnStreamEncoder(csnStream_t* ar, const CSN_DESCR* pDescr, bitvec *vector guint8 bits_to_handle = remaining_bits_len%8; if (bits_to_handle > 0) { - guint8 fl = filler&(0xff>>(8-bits_to_handle)); + /* section 11 of 44.060 + * The padding bits may be the 'null' string. Otherwise, the + * padding bits starts with bit '0', followed by 'spare padding' + * < padding bits > ::= { null | 0 < spare padding > ! < Ignore : 1 bit** = < no string > > } ; + */ + guint8 fl = filler&(0xff>>(8-bits_to_handle + 1)); bitvec_write_field(vector, writeIndex, fl, bits_to_handle); LOGPC(DCSN1, LOGL_NOTICE, "%u|", fl); remaining_bits_len -= bits_to_handle; -- 1.7.9.5

9 years, 3 months

Incorrect Packet Downlink Assignment message in TbfTest.err

by Saurabh Sharan

Hello All, This mail is to highlight the necessity of the "[PATCH] Fix encoding of padding bits to start with 0 bit" In the latest master osmo-pcu 0.2.752-173e, the identified bug in encoding of padding bits is generating incorrect Control message. Example of an incorrect Packet Downlink Assignment message from the current TbfTest.err log is @ line number 3433 Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 0b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b Incorrect encoding has resulted in the analyzer interpreting PFI present with value 21. Whereas with the fix for encoding padding bits result is Sending data request: trx=0 ts=4 sapi=5 arfcn=0 fn=0 block=0 data=4f 08 20 00 44 02 00 02 08 04 00 c0 03 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b Output of the message analyzer(http://www.3gpp-message-analyser.com/) is attached in the mail. Please review the patch and let us know procedure for a merge to master. Regards Saurabh

9 years, 3 months

[PATCH] Add test vectors for EGPRS messages

by Saurabh Sharan

This patch is the test suite modification for the fix encoding of padding bits. New test vectors have been added both in downlink and uplink. Correction in existing test vector is also done. --- tests/rlcmac/RLCMACTest.cpp | 13 ++++++----- tests/rlcmac/RLCMACTest.ok | 50 +++++++++++++++++++++++++++++++++++-------- 2 files changed, 49 insertions(+), 14 deletions(-)

9 years, 3 months

[PATCH] Introduction of new Header Types for FANR

by Prasad.Kaup＠radisys.com

From: Aravind Sirsikar <Arvind.Sirsikar(a)radisys.com> Defines new Header Type structures for FANR Signed-off-by: Prasad Kaup <Prasad.Kaup(a)radisys.com> --- src/rlc.h | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 106 insertions(+), 3 deletions(-) diff --git a/src/rlc.h b/src/rlc.h index f7c5457..81332ce 100644 --- a/src/rlc.h +++ b/src/rlc.h @@ -363,9 +363,55 @@ struct gprs_rlc_dl_header_egprs_1 { uint8_t bsn1_b; uint8_t bsn1_c:1, bsn2_a:7; - uint8_t bsn2_b:3, - cps:5; + cps:5; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.1.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type1 { + uint8_t usf:3, + ces_p:3, + pani:1, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn1_a:2; + uint8_t bsn1_b; + uint8_t bsn1_c:1, + bsn2_a:7; + uint8_t bsn2_b:3, + cps:5; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.2.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type2 { + uint8_t usf:3, + ces_p:3, + pani:1, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn_a:2; + uint8_t bsn_b; + uint8_t bsn_c:1, + cps:3, + dummy:4; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.3.3.2 */ +struct gprs_rlc_dl_header_egprs_fanr_type3 { + uint8_t usf:3, + ces_p:2, + pani:2, + tfi_a:1; + uint8_t tfi_b:4, + pr:2, + bsn_a:2; + uint8_t bsn_b; + uint8_t bsn_c:1, + cps:4, + spb:2, + dummy:1; } __attribute__ ((packed)); struct rlc_li_field { @@ -413,7 +459,7 @@ struct gprs_rlc_ul_header_egprs_2 { dummy:3; } __attribute__ ((packed)); - +/* TS 44.060 10.3a.4.1.1 */ struct gprs_rlc_ul_header_egprs_1 { uint8_t r:1, si:1, @@ -431,6 +477,63 @@ struct gprs_rlc_ul_header_egprs_1 { uint8_t spare2:6, dummy:2; } __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.1.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type1 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + bsn2_a:2; + uint8_t bsn2_b; + uint8_t cps:5, + rsb:1, + pi:1, + pani:1; + uint8_t spare2:6, + dummy:2; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.2.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type2 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + cps_a:2; + uint8_t cps_b:1, + rsb:1, + pi:1, + pani:1, + spare:4; + uint8_t spare1:5, + dummy:3; +} __attribute__ ((packed)); + +/* TS 44.060 10.3a.4.3.2 */ +struct gprs_rlc_ul_header_egprs_fanr_type3 { + uint8_t r:1, + si:1, + cv:4, + tfi_a:2; + uint8_t tfi_b:3, + bsn1_a:5; + uint8_t bsn1_b:6, + cps_a:2; + uint8_t cps_b:2, + spb:2, + rsb:1, + pi:1, + pani:1, + dummy:1; +} __attribute__ ((packed)); + } inline bool gprs_rlc_v_b::is_state(int bsn, const gprs_rlc_dl_bsn_state type) const -- 2.1.4

9 years, 3 months

Public Osmocom User Manuals

by Harald Welte

Dear all, some of you may have already seen it on the RSS feed, on Twitter or on planet.osmocom.org[1]: sysmocom has decided that we will re-release our existing formerly sysmocom-internal User Manuals and VTY reference manuals under GNU GFDL. The hope is that with better documentation we can enable more people to use Osmocom software more easily, leading to more adoption. While those manuals are far from being complete or perfect, I had spent a lot of time in February on further polishing them for the upcoming public release. I do believe they provide a better stasting point than what all of what we had in the wiki (whether old trac or new redmine). The manuals are written in asciidoc[2], with the occasional use of mscgen[3] and graphviz[4], which I believe together are a pretty good set of tools to very efficiently and productively work on documentation, whilst focussing on actual content and not on formatting/syntax like when using docbook-xml or LaTeX. The osmo-gsm-manuals.git repository is pulled by our jenkins installation, which then builds the PDF manuals and pushes them to http://ftp.osmocom.org/docs/latest/ I seriously do hope that we will receive improvements and extensions for the manuals. As the asciidoc source is in yet another git repo, sending patches is as easy as it gets. Holger always states nobody ever contributes to manuals, and I would love to prove him wrong ;) In terms of overlapping information in the wiki and in the manuals: I'm in favor (and in the process) of removing outdated old wiki command line reference and VTY reference sections, and simply referring to the manuals instead. Please do read through the manuals and do send patches, whether it's a spelling fix, improved wording, adding missing information or fixing actual technical mistakes. In tems of further dccumentation improvements, Holger has volunteered to ensure that the Doxygen API of libosmocore is also automatically generated+pushed in a similar fashion to make it publicly web-visible. I'd also encurage everyone to contribute patches to covert those parts of libosmocore.git that don't hve doxygen annotation yet. Thanks in advance! Regards, Harald [1] http://projects.osmocom.org/news/47 [2] http://asciidoc.org/ [3] http://www.mcternan.me.uk/mscgen/ [4] http://www.graphviz.org/ -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 years, 3 months

[PATCH] Add constructors to gprs_rlc_v_b and gprs_rlc_v_n

by msuraev＠sysmocom.de

From: Max <msuraev(a)sysmocom.de> Fixes: Coverity: CID 1351738, 1351737 --- src/rlc.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/rlc.h b/src/rlc.h index 54f28df..93f0399 100644 --- a/src/rlc.h +++ b/src/rlc.h @@ -143,8 +143,7 @@ struct gprs_rlc_v_b { void mark_invalid(int bsn); void reset(); - - + gprs_rlc_v_b(); private: bool is_state(int bsn, const gprs_rlc_dl_bsn_state state) const; void mark(int bsn, const gprs_rlc_dl_bsn_state state); @@ -216,6 +215,7 @@ struct gprs_rlc_v_n { bool is_received(int bsn) const; gprs_rlc_ul_bsn_state state(int bsn) const; + gprs_rlc_v_n(); private: bool is_state(int bsn, const gprs_rlc_ul_bsn_state state) const; void mark(int bsn, const gprs_rlc_ul_bsn_state state); @@ -490,6 +490,16 @@ inline const int16_t gprs_rlc_dl_window::distance() const return (m_v_s - m_v_a) & mod_sns(); } +inline gprs_rlc_v_b::gprs_rlc_v_b() +{ + reset(); +} + +inline gprs_rlc_v_n::gprs_rlc_v_n() +{ + reset(); +} + inline gprs_rlc_ul_window::gprs_rlc_ul_window() : m_v_r(0) , m_v_q(0) -- 2.7.2

9 years, 3 months

[osmo-pcu 0.2.749-22d7] testsuite: 3 failed

by Saurabh Sharan

Hello All, In the latest master, Unit test for TBF is failing. Please find the attached tests/testsuite.log with this mail. I was working on resubmission of padding encoding patch wherein this failure was noticed. Regards Saurabh

9 years, 3 months

Support of Fast Ack/Nack reporting in osmoPCU

by Aravind Sirsikar

Hello All, We are currently working on providing the support of Fast Ack/Nack Reporting(FANR) feature in OsmoPCU. We have Identified and listed major changes in OsmoPCU as below. 1) Introduction of new header types in UL/DL a. Mainly due to presence of CES/P and PANI fields 2) Following Control Messages changes a. Packet Downlink Assignment b. Packet Uplink Assignment c. EGPRS Packet Channel Request 3) MS Radio Capability a. Extraction of Reduced Latency Capability 4) VTY interface changes to enable/disable the feature 5) Downlink PAN Handling 6) Uplink PAN Handling 7) RLC window modification a. Introduction of state variable to manage REPORTED and UNREPORTED states in UL direction b. Introduction of new state TENTATIVE_ACK in DL direction 8) TBF flow changes 9) Handling of Tentative Ack blocks during retransmission Note: There may be impacts on osmo-bts. But the impacts has not been considered yet. We plan to have a separate branch from master for this development. Please let us know your valuable feedback. Thanks, Aravind Sirsikar

9 years, 3 months

Support of 11 bit RACH support in osmoPCU

by Prasad Kaup

Hello All, We are currently working on providing the support of 11 bit RACH support in osmoPCU as mentioned in Bug #1548 at https://projects.osmocom.org/projects/osmopcu/issues We have identified impacts to be in osmo-pcu, osmo-bts and osmocore Main changes identified are osmo-pcu: * In file pcuif_proto.h, modify "uint8_t ra" to "uint16_t ra" in struct gsm_pcu_if_rach_ind * Corresponding function prototypes due to change in data type * 11 bit RACH handling in bts.cpp * Changes in encoding.cpp to support immediate assignment with EGPRS allocation osmocore: * In file l1sap.h, modify "uint8_t ra" to "uint16_t ra" in structure "struct ph_rach_ind_param" * Function prototype changes osmobts: * Function prototype changes due to change in data type Please let us know your valuable feedback. We plan to have a separate branch from master for this development. Please let us know the procedure to do this. Regards Prasad

9 years, 3 months

← Newer
1
...
36
37
38
39
40
41
42
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs