<p>Patch set 1:<span style="border-radius: 3px; display: inline-block; margin: 0 2px; padding: 4px;background-color: #d4ffd4;">Code-Review +1</span></p><p><a href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492">View Change</a></p><p>1 comment:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492/1/src/gprs_rlcmac_sched.cpp">File src/gprs_rlcmac_sched.cpp:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492/1/src/gprs_rlcmac_sched.cpp@463">Patch Set #1, Line 463:</a> <code style="font-family:monospace,monospace"> poll_fn = rts_next_fn(fn, block_nr);</code></p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">So that means that whenever we request USF on FN = x, the PCU expects the response on FN = x + 1.<br>However, I always though that requesting USF on FN = x meant the MS would send the UL block on FN = x too (because there's a UL/DL delay opf a few TS iirc).</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">So if I understand correctly, the question is why do we get an Uplink block on FN = x + 1 and not FN = x? I guess you meant x + 4, or basically the next block here, because FN = x + 1 is where the network would send the 2nd burst of the PDTCH/D block.</p><p style="white-space: pre-wrap; word-wrap: break-word;">Indeed, the Uplink is delayed by 3 timeslot periods from Downlink, but the purpose of this delay is to give the MS some time for tuning from a Downlink frequency to the Uplink frequency. I don't think this applies to (E)GPRS capable phones with full-duplex, but still, this is the general assumption.</p><p style="white-space: pre-wrap; word-wrap: break-word;">What's more important is that the MS needs to receive complete PDTCH block in order to decode it and parse USF from there, this is 4 consecutive bursts on Downlink, and thus 4 consecutive TDMA frames (because there are other timeslots too). Let's me try to explain graphically, so below is a time diagram for one PDCH timeslot. The numbers in squares correspond to 'bid' - the number of burst within a PDTCH block.</p><pre style="font-family: monospace,monospace; white-space: pre-wrap;"> +--{ Fn = x: PCU sends first burst of a PDTCH/D block with USF=0. }<br> |<br> | +--{ Fn = x + 3: MS decodes PDTCH/D block and parses USF=0. }<br> | |<br> +---+---+---+---+---+---+---+---+<br> | 0 | 1 | 2 | 3 | 0 | 1 | 2 | 3 |<br> +---+---+---+---+---+---+---+---+<br> | |<br> | +--{ Fn = x + 4: MS actually sends first burst of PDTCH/U block here. }<br> |<br> +--{ Fn = x: This is where the MS is expected to Tx according to your<br> assumption, but this is one TDMA frame earlier than it gets the<br> last bid=3 of the Downlink frame with USF=0, so too early. }</pre><p style="white-space: pre-wrap; word-wrap: break-word;">To put differently, the UL/DL delay of 3 TDMA timeslot periods is insignificant for what you're describing. You would need a delay of 4 TDMA frames to achieve that ;)</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492">change 23492</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492"/><meta itemprop="name" content="View Change"/></div></div>
<div style="display:none"> Gerrit-Project: osmo-pcu </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: Ia99c9edad6e5bd837e9baeb4fb2683b227887957 </div>
<div style="display:none"> Gerrit-Change-Number: 23492 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Hoernchen <ewild@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: daniel <dwillmann@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <vyanitskiy@sysmocom.de> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: lynxis lazus <lynxis@fe80.eu> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 25 Mar 2021 01:34:50 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-Has-Labels: Yes </div>
<div style="display:none"> Comment-In-Reply-To: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-MessageType: comment </div>