Project

General

Profile

Bug #1883

RACH load computation is wrong

Added by laforge over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/19/2016
Due date:
% Done:

100%

Spec Reference:

Description

l1sap_info_time_ind() is suposed to be called [at least] once every TDMA frame.

To be sure, we count the number of frames expired based on info_time_ind->fn - btsb->gsm_time.fn

[btw: there could/should be an assert or a big fat LOGL_ERROR message if we ever have more than one FN difference]

We then take the number of RACH slots per multiframe (27 or 51, depending on combined/non-combined CCCH) and multiply that with frames_expired. This is clearly wrong.

We should instead check if the currently processed/expired frame number was a rach slot (e.g. by some array index), and if yes increment btsb->load.rach.total by one.


Related issues

Related to OsmoBTS - Feature #1884: distribute measurement processing accross timeslots Closed 12/19/2016

History

#1 Updated by laforge over 1 year ago

It also seems that btsb->load.rach.busy, btsb->load.rach.access and btsb->load.rach.total is always only incremented and never reset. They should probably all be re-set in reset_load_counters() just after we sent a load indication (and thus concluded a load indication period).

#2 Updated by laforge over 1 year ago

  • Related to Feature #1884: distribute measurement processing accross timeslots added

#3 Updated by dexter over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20
Had a look into 3GPP TS 05.02, Clause 7 Table 5 of 9: Mapping of logical channels onto physical channels, see "Random access channel blocks available". From there I deduct:
  • For the non combined case: B0, B1 ... B50 --> Each frame carries a RACH channel --> Increment each time.
  • For the combined case: B4, B5, B14, B15 ... B36, B45, B46 => Only the mentioned blocks contain a rach channel --> Use modulo operation to calculate if the given frame number falls into one of the mentioned blocks, if yes increment.

#4 Updated by dexter over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 20 to 100

The counting of the already expired rach frames is now fixed:

Non combined CCCH:
  • Lookup from SI3 how many physical CCCH channels are used.
  • Multiply the expired frames with that number (we may do this, all of the 51 frames are containing the RACH channel)
  • Multiply the result by 4 (One block is consists of 4 bursts, one rach request only occupies 1 burst ==> 4)
  • Add the final result to the expired rach slot counter
Combined CCCH:
  • Calculate the blocknumber from the framenumber (Modulo 51)
  • Check if that block number falls into a rach block, if yes, multiply expired frames by 4.
  • Add the final result to the expired rach slot counter

See also: https://gerrit.osmocom.org/#/c/1573/

#5 Updated by laforge over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF