T Network Response Time is used to delay the DL TBF release. If it is = 1.6s, it means the TBF DL is kept 1.6s even though the last packet have been sent.
It is a good feature. Almost a mandatory feature..
Basically, after the MS received DL data, the TBF stays open so that DL or UL data can be sent again quickly. It greatly improves the subscriber’s perception of the service : high reactivity, quick response…
It could increase TBF drop, because , basically , the TBF is used for a longer time. The chances of drop are increased proportionally to the duration of the TBF. I guess you get the point 🙂
In the training, you get the detailed procedure of the delayed DL TBF release.
The comments are probably a little old, and the value 0.7s is perhaps an old one. It is the minimum value : it is usually the round trip time between MS and Internet. Keeping the TBF open for this time is the least you can do, to avoid releasing and reestablishing TBF’s all the time. (most downloads are followed by other uploads and again, other dwloads)
I’ll try to dig it further if you need, and as usual, kindly let me know about your experiments. (I never fine-tuned this parameter)