This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Jacob Erlbeck jerlbeck at sysmocom.deHi Ivan, On 13.02.2014 13:48, Ivan Kluchnikov wrote: > First I want to summarize you previous ideas, which I think we should implement: > 1. we shouldn't send Delete Ind message for IMMEDIATE ASSIGNMENT REJECT messages > 2. Just drop IA REJECTs, if L > maxL/2 (am I right?) I'm not sure about which factor to use, especially if maxL is very low. But I think it's a good start. Maybe we need some simulations to fine-tune. In addition, we should add stat counters for that. > 3. Use agch_queue_length and agch_max_queue_length names > 4. Implement function bts_agch_update_max_queue_length, that is only > called after config/bs_ag_blks_res is changed/set (do you know places > where bs_ag_blks_res is changed/set?) We've to check. If any of the input values changes, we have to update. But let's put that call into agch_enqueue initially. Moving this to other places is just an optimization and I would like to defer it, until the rest has proved to work. > 5. Yes, you are right, we can use PCH blocks when needed, it is good > question, why (master and jolly/trx) do not use PCH blocks when > needed. I've just set up a test case with NITB and two phones, and modified code where only the PCH blocks are used for AGCH and PCH and it worked pretty well. > Actually we already have function for that: > int paging_add_imm_ass(struct paging_state *ps, const uint8_t *data, > uint8_t len); > Moreover we should also determine when we should start to use PCH for > imm assign messages and what we should do with agch_max_queue_length > in this case, what do you think about it? I would use PCH for AGCH messages, when there is not pending paging message. And I wouldn't use paging_add_imm_ass() but just call bts_agch_dequeue() when there is no paging message. I wouldn't do this in paging_gen_message() but outside of it, since it is no paging message. agch_max_queue_length should be based on ag_blks_res + gsm0502_get_n_pag_blocks() (or something delivering the same result) then. > 6. What do you finally think about calculating agch_max_queue_length? > What is the right way to calculate it from your point of view? I'm not sure yet. Since there is a direct relationship between number of RACH bursts and CCCH blocks per multiframe, there could be a way to simplify the calculation. One have to adjust it, if there are optional CCCH blocks that are not AGCH/PCH (like CBCH), but even if that is not taken into account, the error might be tolerable. Jacob