Now parameterize on bwp and enable what the title says. Specify nof_bwps in the config file to spawn threads to monitor a particular bwp for a particular RNTI range. Therefore, rename previously nof_threads to nof_rnti_worker_groups, and now the total spawned threads will be nof_rnti_worker_groups * nof_bwps. Created the exit point if > 1 nof_bwps specified yet we could not capture the configs in RRCSetup.
Tested thoroughly on Amarisoft. For example, see logs when 2 bwps are configured on RAN and nof_bwps = 2.
If only the initial bwp is available (e.g., indeed only 1 bwp is configured or other bwps are configured through encrypted RRCConfiguration, which we observed on Mosolab) and nof_bwps > 1, we hit the exit point as expected.
WanHaoRan
commented
4 months ago
Now parameterize on bwp and enable what the title says. Specify
nof_bwpsin the config file to spawn threads to monitor a particular bwp for a particular RNTI range. Therefore, rename previouslynof_threadstonof_rnti_worker_groups, and now the total spawned threads will benof_rnti_worker_groups*nof_bwps. Created the exit point if > 1nof_bwpsspecified yet we could not capture the configs in RRCSetup.Tested thoroughly on Amarisoft. For example, see logs when 2 bwps are configured on RAN and
nof_bwps= 2.stdout_1bwp.log a_1bwp.csv stdout_2bwps.log a_2bwps.csv
If only the initial bwp is available (e.g., indeed only 1 bwp is configured or other bwps are configured through encrypted RRCConfiguration, which we observed on Mosolab) and
nof_bwps> 1, we hit the exit point as expected.