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/osmocom-net-gprs@lists.osmocom.org/.
jolly andreas at eversberg.euVladimir 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. regards, andreas