Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

Reply To: T200 optimal value

#61101
pix
Guest

hi zbigniew,

i may be wrong, or i may have misunderstood your point, so don’t hesitate to correct me ๐Ÿ™‚

T200 supervises the reception of the Ack of a Lapdm frame.

when BTS sends a lapdm I frame (= that requires an ack), the MS has an opportunity to send the ack in the next UL TDMA frame.

For the case of SDCCH. We start to count at TDMA Frame = 0
Let’s assume the BTS needs to send “big” L3 message, that requires a segmentation over 4 SDCCH bursts. It means that the message is going to be segmented in 4 Lapdm frames, each Lapdm “L2” frame is then sent in one TDMA “L1” burst.
the MS receives the 1st burst, which should be acknowledged. That was Frame 0.
Then it receives the 2nd one, and the 3rd one, and the 4th one (they are all sent in consecutive TDMA frames because of the way the SDCCH multiframe is multiplexed)
We are now at the end of frame 4.

So the MS needs to ack the last burst received, the 4th one. It will be able to do so when it is his turn to send his UL SDCCH frame. Which is in frame 15 !

So T200 is running since Frame 0, awaiting for an ack. The frame 15 is just 69ms later. If MS doesn’t send his ACK now, it can still do it in frame 16, 17 or 18.

After T200 (=220ms), the BTS assumes the ACK is “lost”. It is correct for the BTS to assume so : the ack should have arrived a *long* time ago ๐Ÿ™‚
After 235ms, the BTS has the opportunity to repeat the previous SDCCH msg because the ack was not yet received.
If you allow T200 to be longer, then the BTS misses one opportunity to repeat the SDCCH ! Of course, it is possible the MS will acknowledge the 1st message in the second multiframe, but it means the MS is very slow. It is safer to assume that the MS didn’t decode the previous SDCCH msg rather than assume the MS will eventually send an ACK later.

I hope I was clear… and I hope I’m not too far off the truth ๐Ÿ™‚

cheers and thanks for the interesting question !
pix