https://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-11-18T16:12:29ZOpen Source Mobile CommunicationsOsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=254622022-11-18T16:12:29Zpespin
<ul><li><strong>Assignee</strong> set to <i>pespin</i></li></ul><p>This is still not implemented.</p>
<p>I see it from time to time with the MS I have with me. specially after MS attaches or stops sending ping or I send it to flight mode.</p>
<pre>
18170837087 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: Received Event SCHED_ACK
20221118170837087 DTBFUL tbf_ul_ack_fsm.c:109 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: state_chg to SCHED_UL_ACK
20221118170837099 DTBFUL tbf_ul_ack_fsm.c:233 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: Received Event CREATE_RLCMAC_MSG
20221118170837099 DTBFUL tbf_ul_ack_fsm.c:137 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: state_chg to NONE
20221118170837298 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169762, TS=5
20221118170837400 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169784, TS=5
20221118170837441 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169793, TS=5
20221118170837501 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169806, TS=5
20221118170837544 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: Received Event SCHED_ACK
20221118170837544 DTBFUL tbf_ul_ack_fsm.c:109 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: state_chg to SCHED_UL_ACK
20221118170837561 DTBFUL tbf_ul_ack_fsm.c:233 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: Received Event CREATE_RLCMAC_MSG
20221118170837561 DTBFUL tbf_ul_ack_fsm.c:137 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: state_chg to NONE
20221118170837580 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169823, TS=5
20221118170837658 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169840, TS=5
20221118170837686 DTBFUL pdch.cpp:815 TBF(UL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) RX: [PCU <- BTS] FIXME: Packet resource request
20221118170837741 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169858, TS=5
20221118170837819 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169875, TS=5
20221118170837861 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169884, TS=5
20221118170837958 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169905, TS=5
20221118170838125 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: Received Event SCHED_ACK
20221118170838125 DTBFUL tbf_ul_ack_fsm.c:109 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: state_chg to SCHED_UL_ACK
20221118170838138 DTBFUL tbf_ul_ack_fsm.c:233 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: Received Event CREATE_RLCMAC_MSG
20221118170838138 DTBFUL tbf_ul_ack_fsm.c:137 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: state_chg to NONE
20221118170838180 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169953, TS=5
20221118170838185 DTBFUL pdch.cpp:815 TBF(UL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) RX: [PCU <- BTS] FIXME: Packet resource request
20221118170838281 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=169975, TS=5
20221118170838558 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=170035, TS=5
20221118170838587 DTBFUL tbf_ul.cpp:451 UL_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){FLOW}: Received Event LAST_UL_DATA_RECVD
20221118170838587 DTBFUL tbf_ul_fsm.c:197 UL_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){FLOW}: state_chg to FINISHED
20221118170838587 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: Received Event SCHED_ACK
20221118170838587 DTBFUL tbf_ul_ack_fsm.c:109 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){NONE}: state_chg to SCHED_UL_ACK
20221118170838600 DTBFUL tbf_ul_ack_fsm.c:233 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: Received Event CREATE_RLCMAC_MSG
20221118170838600 DTBFUL tbf_ul_ack_fsm.c:135 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){SCHED_UL_ACK}: state_chg to WAIT_ACK
20221118170838605 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){WAIT_ACK}: Received Event SCHED_ACK
20221118170838624 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){WAIT_ACK}: Received Event SCHED_ACK
20221118170838646 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){WAIT_ACK}: Received Event SCHED_ACK
20221118170838665 DTBFUL tbf_ul.cpp:500 UL_ACK_TBF(UL:TFI-0-0-0:STATE-NEW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029){WAIT_ACK}: Received Event SCHED_ACK
20221118170838678 DTBFDL tbf_dl.cpp:803 TBF(DL:TFI-0-0-0:STATE-FLOW:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) Scheduled Ack/Nack polling on FN=170061, TS=5
20221118170838724 DRLCMAC pdch_ul_controller.c:323 PDCH(bts=0,trx=0,ts=5) Timeout for registered POLL (FN=170044, reason=UL_ACK): TBF(UL:TFI-0-0-0:STATE-FINISHED:EGPRS:IMSI-901700000043320:TLLI-0xe0196029)
20221118170838724 DTBF tbf.cpp:519 TBF(UL:TFI-0-0-0:STATE-FINISHED:EGPRS:IMSI-901700000043320:TLLI-0xe0196029) poll timeout for FN=170044, TS=5 (curr FN 170044)
</pre> OsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=254632022-11-18T16:27:23Zpespin
<ul><li><strong>File</strong> <a href="/attachments/5554">pkt_res_req_id_ul_ftfi.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/5554/pkt_res_req_id_ul_ftfi.pcapng">pkt_res_req_id_ul_ftfi.pcapng</a> added</li></ul><p>I attach a pcap rlcmac snippet related to the log lines I just shared above.</p>
<p>It seems to be related to the moment at which the MS receives the Deactive PDP Context. It is sending UL data and the PCU asks the MS to continue sending data by setting the MS's USF (since it's probably unaware of the higher layer DeactivatePDPContext it just sent to it). The MS instead of continuing sending data (last UL block had CV=15) it actually sends the PKT Resource Request, maybe because it ereased it's tx queue after receiving the DeactivatePDPContext?</p>
<p>I need to check the exact reasons why the Pkt resource Req may be sent by the MS there. In any case we should at least parse and apply the measurements from it.</p> OsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=254672022-11-18T18:12:01Zpespin
<ul></ul><p>In another pcap (I can reproduce it frequently when having a tbf with data ongoing with my "motorola G" phone and then going back to flight mode), I see the new UL TBF requested by the MS while the previous one is ongoing has to be with the fact it wants to change the RADIO_PRIORITY and PEAK_THROUGHPUT_CLASS.</p>
<p>In that scenario I usually see 2 of those PKT RES REQ quite in a row, with a few secs of difference. The second one of the PKT RES REQ with UL_TFI seems to be the one the MS sends as a response to the DeactivatePDPContext.</p>
<p>During usual PKT_RESOURCE_REQ for 2phase access (after RACH req+IMM_ASS in CCCH), the MS provides this Channel_Request_Description:<br /><pre>
Channel_Request_Description
..01 10.. = PEAK_THROUGHPUT_CLASS: 6
.... ..11 = RADIO_PRIORITY: 3
0... .... = RLC_MODE: RLC acknowledged mode
.1.. .... = LLC_PDU_TYPE: True
..00 0000 0001 0010 11.. .... = RLC_OCTET_COUNT: 75
..0. .... = Exist_CHANGE_MARK: 0
...1 1000 1... .... = C_VALUE: 49
.0.. .... = Exist_SIGN_VAR: 0
</pre></p>
<p>During the 1st PKT RES REq with exisiting UL_TBF TFI, it looks like this (and that's mostly all the relevant info in the PKT_RES_REQ):<br />GSM RLC/MAC: PACKET_RESOURCE_REQUEST (5) (Uplink)<br /><pre>
Channel_Request_Description
.... ...0 000. .... = PEAK_THROUGHPUT_CLASS: 0
...0 0... = RADIO_PRIORITY: 0
.... .0.. = RLC_MODE: RLC acknowledged mode
.... ..1. = LLC_PDU_TYPE: True
.... ...0 0000 0000 0001 011. = RLC_OCTET_COUNT: 11
.... ...0 = Exist_CHANGE_MARK: 0
1011 01.. = C_VALUE: 45
.... ..0. = Exist_SIGN_VAR: 0
</pre><br />So it seems to basically be indicating the network to change the RADIO_PRIORITY of the TBF (or maybe create a new one with different prio? or create a new one and maintain the older one?).</p>
<p>Then, aprox while receiving the DeactivatePDPContext, the 2nd PKT RES REQ with existing UL_BF TFI looks again like usual:<br /><pre>
Channel_Request_Description
.... ...0 110. .... = PEAK_THROUGHPUT_CLASS: 6
...1 1... = RADIO_PRIORITY: 3
.... .0.. = RLC_MODE: RLC acknowledged mode
.... ..1. = LLC_PDU_TYPE: True
.... ...0 0000 0000 0000 001. = RLC_OCTET_COUNT: 1
.... ...0 = Exist_CHANGE_MARK: 0
1011 01.. = C_VALUE: 45
.... ..0. = Exist_SIGN_VAR: 0
</pre></p>
<p><strong>So it's changing temporarily the usual PEAK_THROUGHPUT_CLASS from 6 ("Up to 256 000 octet/s") to 0 ("Subscribed peak throughput", whatever that means, Table 10.5.156/3GPP TS 24.008) and back.<br />It's also changing temporarily the usual RADIO_PRIORITY from 3 to 0 (highest priority, TS 44.060 Table 11.2.5) and back.</strong></p>
<p><strong>So in the end it looks like the MS is basically asking the network to raise the priority of its UL TBF in order to send something urgent to it, probably the DeactivatePDPContextReq because it wants to go into flight mode quickly.</strong></p>
<p>According to TS 44.060, decription of PACKET RESOURCE REQUEST:<br /><pre>
This message is sent on the PACCH by the mobile station to the network to request a change in the uplink resources
assigned.
</pre></p>
<p>So that seems like valid, but all references I found so far in TS 44.060 seems to indicate the PKT RES REQ is sent as an answer o a POLL request, whereas in this case it's simply the network sending a DL DUMMY BLOCK with USF=0 (hence requesting the UL TBF to send data, but not polling it?).</p>
<p>A while afer the MS sending the PKT RES REQ and us doing nothing about it, the MS still seem to be happily owning and using the old UL TBF to send data. I think that's fine because TS 44.060 states in several places that the USF and TFI can be reused for the same MS.</p> OsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=254702022-11-18T20:09:34Zpespin
<ul></ul><p>8.1.1 Uplink RLC data block transfer</p>
<pre>
In A/Gb mode, during the TBF, if the countdown procedure has not started or the TBF is operated in the extended
uplink TBF mode (see sub-clause 9.3.1b) and multiple TBF procedures are not supported (i.e. the mobile station or the
network does not support multiple TBF procedures) the mobile station shall ask for new or different radio resources, by
sending a PACKET RESOURCE REQUEST message (sub-clauses 8.1.1.1.2), in the following cases;
- When the mobile station has indicated Page Response, Cell update or Mobility Management procedure as access
type in the PACKET CHANNEL REQUEST message and it has data to send;
- When the mobile station has data to send with a lower priority than indicated in the PACKET CHANNEL
REQUEST or EGPRS PACKET CHANNEL REQUEST message;
- When the mobile station has indicated 'Signalling' as access type in the EGPRS PACKET CHANNEL
REQUEST message and it has data to send
</pre>
<p>8.1.1.1.2 Resource Reallocation for Uplink</p>
<pre>
If the mobile station or the network does not support multiple TBF procedures the following procedures apply
- If the mobile station or the network does not support multiple TBF procedures the following procedures apply unless
resource reallocation is not needed when EMSR is enabled (see sub-clause 5.12):
- If the mobile station has not started the countdown procedure or the TBF is operated in the extended uplink TBF
mode (see sub-clause 9.3.1b) and the new upper layer PDU has the same RLC mode as the current uplink TBF,
or in case EMST is used, the new upper layer PDU has the same RLC mode as any of the RLC entities allocated
on the ongoing uplink TBF, and either a higher radio priority or the same radio priority but a higher peak
throughput class, the mobile station shall immediately request a resource reallocation for uplink according to the
new Radio Priority and peak throughput class of the new upper layer PDU by sending a PACKET RESOURCE
REQUEST message on the PACCH and starting timer T3168 for the uplink TBF requested in the PACKET
RESOURCE REQUEST message. Then the mobile station shall complete the transmission of the current upper
layer PDU;
- If the new upper layer PDU has the same RLC mode as the current uplink TBF, or in case EMST is used, the
new upper layer PDU has the same RLC mode as any of the RLC entities allocated to the ongoing uplink TBF,
and either a lower Radio Priority or the same radio priority but a lower peak throughput class, the mobile station
shall first complete the sending of the upper layer PDU in transfer. When the sending of upper layer PDUs at the
higher Radio Priority or the same radio priority but higher peak throughput class stops, without waiting for the
acknowledgement from the network if in RLC acknowledged mode, the mobile station shall then perform the
request of a resource reallocation for uplink for any remaining upper layer PDU(s) by sending a PACKET
RESOURCE REQUEST message on the PACCH and start timer T3168 for the uplink TBF requested in the
PACKET RESOURCE REQUEST message. However if the upper layer PDUs at the higher Radio Priority does
not completely fill the RLC data block the MS shall fill this RLC data block with payload from the new upper
layer PDUs and then either transmit first the PACKET RESOURCE REQUEST message and subsequently the
RLC data block or vice versa.
On receipt of the PACKET RESOURCE REQUEST message the network shall respond by sending either an uplink
assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, PACKET
TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE) or a PACKET ACCESS REJECT
message to the mobile station on the downlink PACCH. If the mobile station supports RLC non-persistent mode the
network may allocate one or more EGPRS TBFs that use this RLC mode.
If the mobile station or the network does not support multiple TBF procedures, then after the transmission of the
PACKET RESOURCE REQUEST message with the reason for changing PFI, the radio priority or peak throughput
class of an assigned uplink TBF the mobile station shall continue to use the currently assigned uplink TBF assuming
that the requested radio priority or peak throughput class is already assigned to that TBF.
If the mobile station or the network does not support multiple TBF procedures, upon expiry of timer T3168 the mobile
station shall retransmit the PACKET RESOURCE REQUEST message unless the PACKET RESOURCE REQUEST
message has already been transmitted four times in which case the mobile station shall perform an abnormal release
with access retry (see sub-clause 8.7.2).
</pre>
<p>So it's clear according to 8.1.1.1.2 that we should be reallocating + sending a PKT Ul Ass to the MS but we are not doing it.</p>
<p>This also clarifies that indeed an MS can send a PKT RESOURCE REQUEST when it wishes (as requested by matching USF) and not only when polled. This is important because the code path triggered by USF is not propelry handled with ID=TLLI in gprs_rlcmac_pdch::rcv_resource_request():</p>
<pre>
case PDCH_ULC_NODE_TBF_USF:
/* Is it actually valid for an MS to send a PKT Res Req during USF? */
ul_tbf = item->tbf_usf.ul_tbf;
LOGPDCH(this, DRLCMAC, LOGL_NOTICE, "FN=%u PKT RESOURCE REQ: "
"Unexpectedly received, waiting USF of %s\n",
fn, tbf_name(item->tbf_usf.ul_tbf));
/* Ignore it, let common path expire related ULC entry */
goto return_unref;
</pre>
<p>As far as I can tell we can refactor gprs_rlcmac_pdch::rcv_resource_request() to first find out the MS based on UL-TFI/DL-TFI/TLLI, and then potentially apply the same code for all (maybe some stuff may need to be changed, like contention resolution, etc?).</p> OsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=255842022-11-24T15:23:52Zpespin
<ul></ul><p>I submitted a first improvement here:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/30293">https://gerrit.osmocom.org/c/osmo-pcu/+/30293</a> pdch: Initial support Handling PktResReq with ID_TYPE=UL/DL_TFI</p>
<p>This is still not perfect since we are freeing the old TBF, while in this case we'd probably want to keep it for a while, at least until we receive the PKT_CONTROL_ACK for the PKT_UL_ASS, or even forever and never create a new UL TBF, since the MS only really expects to get higher priority.</p> OsmoPCU - Bug #4947: osmo-pcu: Handling for Pkt Resource Req using Global TFI not implementedhttps://osmocom.org/issues/4947?journal_id=258642022-12-22T13:04:21Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Stalled</i></li></ul>