Hi Ivan,
On 13.02.2014 13:48, Ivan Kluchnikov wrote:
First I want to summarize you previous ideas, which I think we should implement:
- we shouldn't send Delete Ind message for IMMEDIATE ASSIGNMENT REJECT messages
- 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.
- Use agch_queue_length and agch_max_queue_length names
- 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.
- 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.
- 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