openbts-p2.8-gprs-exp and pcu issues

jolly andreas at
Sat Oct 27 05:15:33 UTC 2012

Vladimir Rolbin wrote:
> <0002> gprs_rlcmac_data.cpp:1183 TX: START TFI: 0 Immediate Assignment
> Uplink (AGCH)
> <0002> gprs_rlcmac_data.cpp:1895 Got IMM.ASS confirm, but rest octets
> do not start with bit sequence 'HH01' (Packet Downlink Assignment)
> <0006> gprs_rlcmac_sched.cpp:260 Received RTS for PDCH: TRX=0 TS=7
> FN=168510 block_nr=7 scheduling free USF for polling at FN=168514 of
> DL TFI=1
> <0002> gprs_rlcmac_data.cpp:395 PACKET DOWNLINK ACK with unknown
> FN=168519 TFI=1 (TRX 0 TS 7)
> <0002> gprs_rlcmac_data.cpp:100 Poll timeout for DL TBF=1
hi vladimir,

there seems to be several problems. i can clearly see the two above:

PCU sends immediate assignment message to BTS. it consists of three
bytes with the last three digits of the IMSI, plus the complete IMM.ASS
message including pseudo length byte and padding. the assignment seems
ok, because the phone follows the assignment. the IMM.ASS confirm from
BTS must not include the three digits of IMSI, but the complete message.
the confirm must be sent to PCU after the assignment is sent (or
sheduled) on PCH. this is required, because it may take seconds,
depending on paging group configuration.

the second problem is wrong scheduling. if you would have set drlcmac
debugging, you would see when polling is scheduled. the scheduled FN
must be 13 bursts (3 blocks) in advance of the RTS FN. 8 or 9 bursts
later, the scheduler must schedule "free USF for polling" for the next
block, which is 4 or 5 bursts later. since i don't see the drlcmac
debugging in your log, i cannot verify it.



More information about the osmocom-net-gprs mailing list