You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

126 lines
3.8 KiB
C

/**
* Copyright 2013-2021 Software Radio Systems Limited
*
* This file is part of srsRAN.
*
* srsRAN is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License as
* published by the Free Software Foundation, either version 3 of
* the License, or (at your option) any later version.
*
* srsRAN is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* A copy of the GNU Affero General Public License can be found in
* the LICENSE file in the top-level directory of this distribution
* and at http://www.gnu.org/licenses/.
*
*/
#ifndef SRSUE_PROC_BSR_H
#define SRSUE_PROC_BSR_H
#include <map>
#include <stdint.h>
#include "proc_sr.h"
#include "srsran/common/task_scheduler.h"
#include "srsran/srslog/srslog.h"
#include "srsue/hdr/stack/mac_common/mac_common.h"
/* Buffer status report procedure */
namespace srsue {
class rlc_interface_mac;
// BSR interface for MUX
class bsr_interface_mux
{
public:
typedef enum { LONG_BSR, SHORT_BSR, TRUNC_BSR } bsr_format_t;
typedef struct {
bsr_format_t format;
uint32_t buff_size[4];
} bsr_t;
/* MUX calls BSR to check if it should send (and can fit) a BSR into PDU */
virtual bool need_to_send_bsr_on_ul_grant(uint32_t grant_size, uint32_t total_data, bsr_t* bsr) = 0;
/* MUX calls BSR to let it generate a padding BSR if there is space in PDU */
virtual bool generate_padding_bsr(uint32_t nof_padding_bytes, bsr_t* bsr) = 0;
proc_bsr: fix race condition in BSR reporting fix for #1934 This fixes a race condition between Stack thread and DL PDU processing that lead to updates of the RLC buffer that are undetected by the BSR routine. What happens is that in a UL SCH PDU all outstanding data is transmitted and and a LBSR with all zero buffers is sent. 14:39:47.327301 [MAC ] [D] [ 3793] BSR: LCID=3 old_buffer=59 14:39:47.330600 [MAC ] [I] [ 3793] UL LCID=3 len=58 LBSR: b=0 0 0 0 Note that "old_buffer" isn't set to zero here. At the same time (same TTI), the MAC PDU processing thread handles DL-SCH PDUs that may generate new UL PDUs: 14:39:47.330749 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=1) 14:39:47.330762 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=2) 14:39:47.330775 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=3) .. Those PDUs are "new data" since the previous buffer state was zero. Here is the race now between the threads, at the end of the bsr::step() function old_buffer of each LCG is updated with the previous new_buffer, so the buffer state of LCG=2 is now 59. Now MAC starts the next TTI: 14:39:47.331910 [MAC ] [D] [ 3794] Running MAC tti=3794 14:39:47.331928 [MAC ] [D] [ 3794] Update Bj: lcid=0, Bj=0 14:39:47.331934 [MAC ] [D] [ 3794] Update Bj: lcid=1, Bj=0 14:39:47.331938 [MAC ] [D] [ 3794] Update Bj: lcid=2, Bj=0 14:39:47.331941 [MAC ] [D] [ 3794] Update Bj: lcid=3, Bj=-1752 14:39:47.331951 [MAC ] [D] [ 3794] BSR: LCID=0 update new buffer=0 14:39:47.331960 [MAC ] [D] [ 3794] BSR: LCID=1 update new buffer=0 14:39:47.331964 [MAC ] [D] [ 3794] BSR: LCID=2 update new buffer=0 14:39:47.331971 [MAC ] [D] [ 3794] BSR: LCID=3 update new buffer=335 14:39:47.331976 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(0)=0 14:39:47.331980 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(1)=0 14:39:47.331984 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(2)=59 14:39:47.331988 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(3)=0 14:39:47.331993 [MAC ] [D] [ 3794] BSR: LCID=0 old_buffer=0 14:39:47.332000 [MAC ] [D] [ 3794] BSR: LCID=1 old_buffer=0 14:39:47.332003 [MAC ] [D] [ 3794] BSR: LCID=2 old_buffer=0 14:39:47.332007 [MAC ] [D] [ 3794] BSR: LCID=3 old_buffer=335 And since the buffer state of LCG=2 isn't zero, the new data for LCID=3 of that LCG is considered. So effectivly, the BSR missed the "empty" buffer state for a fraction of time and doesn't consider the outgoing data generated in the same TTI as new. It therefore doesn't transmit a BSR. in which a BSR wasn't
4 years ago
/* MUX calls BSR to update buffer state of each LCG after all PDUs for this TTI have been packed */
virtual void update_bsr_tti_end(const bsr_t* bsr) = 0;
};
class bsr_proc : public srsran::timer_callback, public bsr_interface_mux
{
public:
Upgrade loggers in srsue (#2163) * Replaced UE logger in the ue class. * Replaced loggers in the main phy class and prach. * Replaced loggers in phy common and ta_control. * Replace loggers in cc and sf workers. * Replaced loggers in intra_measure, scell_recv, search, sfn_sync, sync. * Remove last uses of the old loggers in the main phy class. * Remove stray newline in logs. * Replaced loggers in ue gw. * - Started to replace loggers in the ue stack. - Replaced loggers in usim and pcsc. - Adapted nas and usim tests. * Replace loggers in nas. * Added missing log init calls in two previously modified tests. * Replaced logger in nas idle procs. * Replaced loggers in nas emm state. * Replaced loggers in tft packet filter and adapted tft test. * Replaced loggers in main RRC class. * Replaced loggers in RRC cell. * Replaced loggers in RRC meas. * Replaced loggers in rrc procedures. * Started logger replacement in MAC layer, more precisely in demux and dl_harq classes. Been unable to inject loggers in construction for dl_tb_process due to very weird static assertions in the std::vector code being the type not constructible which is not true, so instead use the main MAC logger directly. * Replaced loggers in mac mux class. * Replaced loggers in mac pro_bsr. * Replaced loggers in mac proc phr. * Replaced loggers in mac proc SR and RA. * Replace loggers in mac UL HARQ. * Replaced loggers in main ue stack class. * Fixed nas test crashing due to a null string. * Ported mac_test to use the new loggers. * Removed TTI reporting for the PHY log as the old logger did. * Replaced loggers in UE phy tests. * Configure loggers in nas_test. * Replaced loggers in rrc_meas_test. * Replaced loggers in rrc_reconfig_test. * Added missing newline in tft_test. * Fix compilation errors in TTCN3 tests. * Fix linker error detected in CI and warning. * Replaced loggers in TTCN3 tests. * Fix a text replace error in some log messages. * Remove trailing newlines from log entries. * Remove old logger from rrc. * Flush backend before printing the test status. * - Fix compilation error from previous rebase. - Remove trailing newlines from some missing log entries.
4 years ago
explicit bsr_proc(srslog::basic_logger& logger) : logger(logger) {}
void init(sr_proc* sr_proc, rlc_interface_mac* rlc, srsran::ext_task_sched_handle* task_sched_);
void step(uint32_t tti);
void reset();
void set_config(srsran::bsr_cfg_t& bsr_cfg);
void setup_lcid(uint32_t lcid, uint32_t lcg, uint32_t priority);
void timer_expired(uint32_t timer_id);
uint32_t get_buffer_state();
bool need_to_send_bsr_on_ul_grant(uint32_t grant_size, uint32_t total_data, bsr_t* bsr);
bool generate_padding_bsr(uint32_t nof_padding_bytes, bsr_t* bsr);
proc_bsr: fix race condition in BSR reporting fix for #1934 This fixes a race condition between Stack thread and DL PDU processing that lead to updates of the RLC buffer that are undetected by the BSR routine. What happens is that in a UL SCH PDU all outstanding data is transmitted and and a LBSR with all zero buffers is sent. 14:39:47.327301 [MAC ] [D] [ 3793] BSR: LCID=3 old_buffer=59 14:39:47.330600 [MAC ] [I] [ 3793] UL LCID=3 len=58 LBSR: b=0 0 0 0 Note that "old_buffer" isn't set to zero here. At the same time (same TTI), the MAC PDU processing thread handles DL-SCH PDUs that may generate new UL PDUs: 14:39:47.330749 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=1) 14:39:47.330762 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=2) 14:39:47.330775 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=3) .. Those PDUs are "new data" since the previous buffer state was zero. Here is the race now between the threads, at the end of the bsr::step() function old_buffer of each LCG is updated with the previous new_buffer, so the buffer state of LCG=2 is now 59. Now MAC starts the next TTI: 14:39:47.331910 [MAC ] [D] [ 3794] Running MAC tti=3794 14:39:47.331928 [MAC ] [D] [ 3794] Update Bj: lcid=0, Bj=0 14:39:47.331934 [MAC ] [D] [ 3794] Update Bj: lcid=1, Bj=0 14:39:47.331938 [MAC ] [D] [ 3794] Update Bj: lcid=2, Bj=0 14:39:47.331941 [MAC ] [D] [ 3794] Update Bj: lcid=3, Bj=-1752 14:39:47.331951 [MAC ] [D] [ 3794] BSR: LCID=0 update new buffer=0 14:39:47.331960 [MAC ] [D] [ 3794] BSR: LCID=1 update new buffer=0 14:39:47.331964 [MAC ] [D] [ 3794] BSR: LCID=2 update new buffer=0 14:39:47.331971 [MAC ] [D] [ 3794] BSR: LCID=3 update new buffer=335 14:39:47.331976 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(0)=0 14:39:47.331980 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(1)=0 14:39:47.331984 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(2)=59 14:39:47.331988 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(3)=0 14:39:47.331993 [MAC ] [D] [ 3794] BSR: LCID=0 old_buffer=0 14:39:47.332000 [MAC ] [D] [ 3794] BSR: LCID=1 old_buffer=0 14:39:47.332003 [MAC ] [D] [ 3794] BSR: LCID=2 old_buffer=0 14:39:47.332007 [MAC ] [D] [ 3794] BSR: LCID=3 old_buffer=335 And since the buffer state of LCG=2 isn't zero, the new data for LCID=3 of that LCG is considered. So effectivly, the BSR missed the "empty" buffer state for a fraction of time and doesn't consider the outgoing data generated in the same TTI as new. It therefore doesn't transmit a BSR. in which a BSR wasn't
4 years ago
void update_bsr_tti_end(const bsr_t* bsr);
private:
const static int QUEUE_STATUS_PERIOD_MS = 1000;
std::mutex mutex;
srsran::ext_task_sched_handle* task_sched = nullptr;
Upgrade loggers in srsue (#2163) * Replaced UE logger in the ue class. * Replaced loggers in the main phy class and prach. * Replaced loggers in phy common and ta_control. * Replace loggers in cc and sf workers. * Replaced loggers in intra_measure, scell_recv, search, sfn_sync, sync. * Remove last uses of the old loggers in the main phy class. * Remove stray newline in logs. * Replaced loggers in ue gw. * - Started to replace loggers in the ue stack. - Replaced loggers in usim and pcsc. - Adapted nas and usim tests. * Replace loggers in nas. * Added missing log init calls in two previously modified tests. * Replaced logger in nas idle procs. * Replaced loggers in nas emm state. * Replaced loggers in tft packet filter and adapted tft test. * Replaced loggers in main RRC class. * Replaced loggers in RRC cell. * Replaced loggers in RRC meas. * Replaced loggers in rrc procedures. * Started logger replacement in MAC layer, more precisely in demux and dl_harq classes. Been unable to inject loggers in construction for dl_tb_process due to very weird static assertions in the std::vector code being the type not constructible which is not true, so instead use the main MAC logger directly. * Replaced loggers in mac mux class. * Replaced loggers in mac pro_bsr. * Replaced loggers in mac proc phr. * Replaced loggers in mac proc SR and RA. * Replace loggers in mac UL HARQ. * Replaced loggers in main ue stack class. * Fixed nas test crashing due to a null string. * Ported mac_test to use the new loggers. * Removed TTI reporting for the PHY log as the old logger did. * Replaced loggers in UE phy tests. * Configure loggers in nas_test. * Replaced loggers in rrc_meas_test. * Replaced loggers in rrc_reconfig_test. * Added missing newline in tft_test. * Fix compilation errors in TTCN3 tests. * Fix linker error detected in CI and warning. * Replaced loggers in TTCN3 tests. * Fix a text replace error in some log messages. * Remove trailing newlines from log entries. * Remove old logger from rrc. * Flush backend before printing the test status. * - Fix compilation error from previous rebase. - Remove trailing newlines from some missing log entries.
4 years ago
srslog::basic_logger& logger;
rlc_interface_mac* rlc = nullptr;
sr_proc* sr = nullptr;
srsran::bsr_cfg_t bsr_cfg;
bool initiated = false;
const static int NOF_LCG = 4;
typedef struct {
int priority;
uint32_t old_buffer;
uint32_t new_buffer;
} lcid_t;
std::map<uint32_t, lcid_t> lcgs[NOF_LCG]; // groups LCID in LCG
mac_buffer_states_t old_buffer_state;
uint32_t find_max_priority_lcg_with_data();
bsr_trigger_type_t triggered_bsr_type = NONE;
void print_state();
void set_trigger(bsr_trigger_type_t new_trigger);
void update_new_data();
proc_bsr: fix race condition in BSR reporting fix for #1934 This fixes a race condition between Stack thread and DL PDU processing that lead to updates of the RLC buffer that are undetected by the BSR routine. What happens is that in a UL SCH PDU all outstanding data is transmitted and and a LBSR with all zero buffers is sent. 14:39:47.327301 [MAC ] [D] [ 3793] BSR: LCID=3 old_buffer=59 14:39:47.330600 [MAC ] [I] [ 3793] UL LCID=3 len=58 LBSR: b=0 0 0 0 Note that "old_buffer" isn't set to zero here. At the same time (same TTI), the MAC PDU processing thread handles DL-SCH PDUs that may generate new UL PDUs: 14:39:47.330749 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=1) 14:39:47.330762 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=2) 14:39:47.330775 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=3) .. Those PDUs are "new data" since the previous buffer state was zero. Here is the race now between the threads, at the end of the bsr::step() function old_buffer of each LCG is updated with the previous new_buffer, so the buffer state of LCG=2 is now 59. Now MAC starts the next TTI: 14:39:47.331910 [MAC ] [D] [ 3794] Running MAC tti=3794 14:39:47.331928 [MAC ] [D] [ 3794] Update Bj: lcid=0, Bj=0 14:39:47.331934 [MAC ] [D] [ 3794] Update Bj: lcid=1, Bj=0 14:39:47.331938 [MAC ] [D] [ 3794] Update Bj: lcid=2, Bj=0 14:39:47.331941 [MAC ] [D] [ 3794] Update Bj: lcid=3, Bj=-1752 14:39:47.331951 [MAC ] [D] [ 3794] BSR: LCID=0 update new buffer=0 14:39:47.331960 [MAC ] [D] [ 3794] BSR: LCID=1 update new buffer=0 14:39:47.331964 [MAC ] [D] [ 3794] BSR: LCID=2 update new buffer=0 14:39:47.331971 [MAC ] [D] [ 3794] BSR: LCID=3 update new buffer=335 14:39:47.331976 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(0)=0 14:39:47.331980 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(1)=0 14:39:47.331984 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(2)=59 14:39:47.331988 [MAC ] [D] [ 3794] BSR: check_new_data() -> get_buffer_state_lcg(3)=0 14:39:47.331993 [MAC ] [D] [ 3794] BSR: LCID=0 old_buffer=0 14:39:47.332000 [MAC ] [D] [ 3794] BSR: LCID=1 old_buffer=0 14:39:47.332003 [MAC ] [D] [ 3794] BSR: LCID=2 old_buffer=0 14:39:47.332007 [MAC ] [D] [ 3794] BSR: LCID=3 old_buffer=335 And since the buffer state of LCG=2 isn't zero, the new data for LCID=3 of that LCG is considered. So effectivly, the BSR missed the "empty" buffer state for a fraction of time and doesn't consider the outgoing data generated in the same TTI as new. It therefore doesn't transmit a BSR. in which a BSR wasn't
4 years ago
void update_old_buffer();
bool check_highest_channel();
bool check_new_data();
bool check_any_channel();
uint32_t get_buffer_state_lcg(uint32_t lcg);
bool generate_bsr(bsr_t* bsr, uint32_t nof_padding_bytes);
char* bsr_type_tostring(bsr_trigger_type_t type);
char* bsr_format_tostring(bsr_format_t format);
srsran::timer_handler::unique_timer timer_periodic;
srsran::timer_handler::unique_timer timer_retx;
srsran::timer_handler::unique_timer timer_queue_status_print;
};
} // namespace srsue
#endif // SRSUE_PROC_BSR_H