Project

General

Profile

Bug #4719

osmo-pcu: MS pinging producing "no resource request scheduled" logs upon Packet Measurement Report received

Added by pespin 2 months ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/18/2020
Due date:
% Done:

90%

Spec Reference:

Description

Reproduce:
  • Setup network using EGPRS
  • Register an MS, eg using android
  • Use adb shell and issue "ping 8.8.8.8", which will attempt pinging around 1 per sec.

Almost every second, some messages like this will appear (notice log level enabled):

20200818182349769 DTBF tbf.cpp:806 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) poll timeout for FN=1313299, TS=6 (curr FN 1313364)
20200818182349769 DTBF tbf.cpp:877 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Timeout for polling PACKET DOWNLINK ACK.
20200818182349769 DTBF tbf.cpp:1177 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Assignment was on PACCH
20200818182349769 DTBF tbf.cpp:1183 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Downlink ACK was received
20200818182354011 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182356987 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182400888 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182405051 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182408928 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182412587 DRLCMAC pdch.cpp:659 MS send measurement in packet resource request of single block, but there is no resource request scheduled! TLLI=0xc17b17fc
20200818182412828 DTBF tbf.cpp:806 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) poll timeout for FN=1318299, TS=6 (curr FN 1318360)
20200818182412828 DTBF tbf.cpp:877 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Timeout for polling PACKET DOWNLINK ACK.
20200818182412828 DTBF tbf.cpp:1177 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Assignment was on PACCH
20200818182412828 DTBF tbf.cpp:1183 TBF(TFI=0 TLLI=0xc17b17fc DIR=DL STATE=FLOW EGPRS) Downlink ACK was received

Related code:

void gprs_rlcmac_pdch::rcv_measurement_report(Packet_Measurement_Report_t *report, uint32_t fn)
{
    struct gprs_rlcmac_sba *sba;

    sba = bts()->sba()->find(this, fn);
    if (!sba) {
        LOGP(DRLCMAC, LOGL_NOTICE, "MS send measurement " 
            "in packet resource request of single " 
            "block, but there is no resource request " 
            "scheduled! TLLI=0x%08x\n", report->TLLI);
    } else {
        GprsMs *ms = bts()->ms_store().get_ms(report->TLLI);
        if (!ms)
            LOGP(DRLCMAC, LOGL_NOTICE, "MS send measurement " 
                "but TLLI 0x%08x is unknown\n", report->TLLI);
        else
            ms->set_ta(sba->ta);

        bts()->sba()->free_sba(sba);
    }
    gprs_rlcmac_meas_rep(report);
}

I attach a related pcap file recorded which contain "PACKET_MEASUREMENT_REPORT" messages (Uplink) received at osmo-pcu, and which are generating the warnings.
They seem to be sent every 4 seconds aprox.
That's more or less matches with what I read from specs (TS 44.016, 5.6.1 Network Control (NC) measurement reporting).
So as far as I understand, it's totally expected that we receive a Measurement Report without having no Single Block Allocation requested. so that log message shouldn't be at least a NOTICE level.

There's however one situation where the network may request a measurement explicitly allocating an SBA, see TS 44.016 "7.3 Procedure for measurement report sending in packet idle mode":

The packet access procedure is initiated by the RR entity in the mobile station as specified in sub-clauses 7.1.2.1 and 7.1.2.2 but with access type "Single block without TBF establishment" indicated in the PACKET CHANNEL REQUEST message. 
...
7.3.1.2 On receipt of a PACKET UPLINK ASSIGNMENT message
When receiving a PACKET UPLINK ASSIGNMENT message the mobile station shall send either the PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message in the allocated radio block on the assigned PDCH and immediately switch back to the PCCCH in non-DRX mode (see sub-clause 5.5.1.5). No TBF is established and the network shall not acknowledge the reception of the PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message. The PACKET MEASUREMENT REPORT message shall contain the NC Measurement Report struct. If timer T3170 expires before a PACKET UPLINK ASSIGNMENT message is received, the packet access procedure is aborted, the transmission of the measurement report for that measurement period is cancelled, and the mobile station shall indicate a random access failure to upper layer and perform autonomous cell re-selection. 

The above is also explained specifically for CCCH config (the one we use) in "7.3.2 Measurement report sending procedure initiated on CCCH":

The mobile station sends a CHANNEL REQUEST message indicating "Single block packet access' on RACH. The network shall then respond with either an IMMEDIATE ASSIGNMENT message granting a "single block access" on a PDCH or an IMMEDIATE ASSIGNMENT REJECT message (see 3GPP TS 44.018). If a PDCH block is assigned, the mobile station shall send either the PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message in the allocated radio block on the assigned PDCH and then immediately switch back to the CCCH in non-DRX mode (see sub-clause 5.5.1.5). No TBF is established and the network shall not acknowledge the reception of the PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message. The PACKET MEASUREMENT REPORT message shall contain the NC Measurement Report struct. 

So it seems what's implemented in osmo-pcu is this scenario, but the log line I see implies the other scenario (MS not in packet idle mode) is not expected in there.

BTW, the related code (SBA in PKT MEAS REPORT) seems to be introduced here:

commit a004e6a8233695abd417a97d6f81a802b605038a
Author: Andreas Eversberg <jolly@eversberg.eu>
Date:   Mon May 13 16:45:21 2013 +0200

    Added timing advance support for up and downlink TBFs

History

#1 Updated by pespin 2 months ago

  • Status changed from New to In Progress

The scenario I'm facing seems to be documented in TS 44.060 "8.3 Procedure for measurement report sending in Packet Transfer mode".

More related information: TS 44.160 "5.5.2 Network Control (NC) measurement reporting"

3GPP TS 45.008 seems to also contain related information.

I think we should simply drop the following NOTICE message. I'll prepare a patch and submit it.

#3 Updated by pespin 2 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 90

Should be fixed by:
https://gerrit.osmocom.org/c/osmo-pcu/+/19705 pdch: Drop unneeded notice log message in rcv pkt meas report

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)