Unbounded AGCH queue in OsmoBTS

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.de
Thu Feb 13 11:07:43 UTC 2014


Hi,

On 11.02.2014 15:07, Jacob Erlbeck wrote:
>> 2. Implemented calculation of  agch queue length.
>> Bts should calculate allowed length of agch queue, because bts should
>> send imm assign message before immediate assignment procedure will be
>> aborted by MS.
>> Imm assign message can be queued no longer than T3126, so agch queue
>> length should be equal (T3126 / 51 ) * bs_ag_blks_res.

My understanding of GSM 05.02 3.3.2.3, 6.5.1 v), and clause 7 table 5
was, that bs_ag_blks_res defines the number of blocks _reserved_ for
AGCH an SI messages per 51-multiframe, but does not _limit_ it.
Is this correct? If yes, is there a reason why the implementations
(master and jolly/trx) do not use PCH blocks when needed?

> 
> I'm not sure about the correctness of the max length calculation because of
> a) There are other timers/conditions that are influenced by the queue delay:
>    - T3101 limits channel reservation on the network side.
>    - Only the last 3 CHANNEL REQUEST messages are matched by the MS
>      against incoming IMMEDIATE ASSIGNMENT messages.

More precisely, this limits the allowable delay to 3*(S+T/2) while
CHANNEL REQUESTs are being sent. After the last one, T3126 is relevant.
At least, this is my understanding of GSM 04.08, 3.3.1.1.2. So I'd
rather drop that requirement, since 3S+1.5T > 2S+T.

Jacob





More information about the OpenBSC mailing list