Change in osmo-pcu[master]: Track scheduled UL blocks through USF

[fixeria]

fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/23492 )

Change subject: Track scheduled UL blocks through USF
......................................................................


Patch Set 1: Code-Review+1

(1 comment)

https://gerrit.osmocom.org/c/osmo-pcu/+/23492/1/src/gprs_rlcmac_sched.cpp 
File src/gprs_rlcmac_sched.cpp:

https://gerrit.osmocom.org/c/osmo-pcu/+/23492/1/src/gprs_rlcmac_sched.cpp@463 
PS1, Line 463: 	poll_fn = rts_next_fn(fn, block_nr);
> So that means that whenever we request USF on FN = x, the PCU expects the response on FN = x + 1.
> 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).

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.

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.

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.

   +--{ Fn = x: PCU sends first burst of a PDTCH/D block with USF=0. }
   |
   |             +--{ Fn = x + 3: MS decodes PDTCH/D block and parses USF=0. }
   |             |
  +---+---+---+---+---+---+---+---+
  | 0 | 1 | 2 | 3 | 0 | 1 | 2 | 3 |
  +---+---+---+---+---+---+---+---+
   |               |
   |               +--{ Fn = x + 4: MS actually sends first burst of PDTCH/U block here. }
   |
   +--{ Fn = x: This is where the MS is expected to Tx according to your
        assumption, but this is one TDMA frame earlier than it gets the
        last bid=3 of the Downlink frame with USF=0, so too early. }

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 ;)



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/23492
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: Ia99c9edad6e5bd837e9baeb4fb2683b227887957
Gerrit-Change-Number: 23492
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: lynxis lazus <lynxis at fe80.eu>
Gerrit-Comment-Date: Thu, 25 Mar 2021 01:34:50 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: pespin <pespin at sysmocom.de>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210325/07d97ba6/attachment.htm>