Support #4657
closedPCU_Tests: Add test to verify MS can ask for a new TBF using Est field in the PACKET UPLINK ACK/NACK
100%
Description
3GPP TS 44.060 sec "9.3.2.4.2 Non-extended uplink TBF mode":
When the mobile station has sent the RLC data block with CV = 0 and there are no elements in the V(B) array set to the value Nacked, it shall start timer T3182 for this TBF. The mobile station shall continue to send RLC data blocks on each assigned uplink data block, according to the algorithm defined in sub-clause 9.1.3. If the network has received all RLC data blocks when it detects the end of the TBF (i.e. when CV=0 and V(Q) = V(R)), it shall send the PACKET UPLINK ACK/NACK message with the Final Ack Indicator bit set to '1', include a valid RRBP field in the RLC/MAC control block header and clear counter N3103 for the TBF. The network may use the TBF Est field in the PACKET UPLINK ACK/NACK message to allow the mobile station to request the establishment of a new uplink TBF if there are no additional TBFs ongoing for that mobile station. If the network has not received all of the RLC data blocks when it detects the end of the TBF, it shall send a PACKET UPLINK ACK/NACK message to the mobile station and if necessary allocate sufficient uplink resources for the mobile station to retransmit the required RLC data blocks.
It then further explains what are the possibilities for the MS to request a new TBF. In our case:
If Control Ack Type parameter in System Information indicates acknowledgement is RLC/MAC control block, the mobile station shall transmit the PACKET RESOURCE REQUEST message and start timer T3168 for the TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two phase access described in sub-clause 7.1.3 starting from the point where the mobile station transmits the PACKET RESOURCE REQUEST message.
So it should be easy to add a test requesting a UL TBF, then sending a few blocks until CV=0, then see what the network sends us upon last UPLINK ACK message and send a PKT Resource Request, and submit some more UL data.
Updated by pespin almost 4 years ago
- Status changed from New to In Progress
current state: test WIP.
I first had to fix a dissector issue in current wireshark master not showng the TBF_EST field (and others from Additions R99):
https://code.wireshark.org/review/37776 rlcmac: Decode properly Pkt Ul ACK/NACK R99 Additions
Once applied, and also checking osmo-pcu, we can see that osmo-pcu correcty passes TBF_EST=1 during Final Ack=1 (reminder to check both values in the test).
Updated by pespin almost 4 years ago
- % Done changed from 0 to 50
Submitted first patch version here as WIP:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19177 pcu: Introduce test TC_ul_tbf_reestablish_with_pkt_resource_req
- Test is still missing checking the values of TBF_EST and FinalACK.
- osmo-pcu prints this message (which btw I saw a lot while operating in my network), which looks wrong and should be removed: "MS requests UL TBF in packet resource request of single block, but there is no resource request scheduled!"
- looking at gsmtap logs, osmo-pcu seems to first create a dummy MS and later attach to the existing one. This can be probably cleaned.
Finally, we also may want to test the other way of creating a new TBF, as stated in the specs references I shared above.
Updated by pespin almost 4 years ago
- % Done changed from 50 to 70
I submitted a bunch of osmo-pcu patches improving code around PKT RESOURCE REQ based on what I saw in the TTCN3 I submitted.
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/19194 pdch.cpp: Avoid dropping existing DL TBF during rcv_resource_request
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/19195 pdch.cpp: Avoid resetting (egprs_)ms_class to unknown if not found in MS ...
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/19196 pdch.cpp: Fix wrong annoying log line about non-scheduled ResourceReq received
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/19197 pdch.cpp: Store TLLI promply on newly created TLLI in rcv_resource_request
- Get test and osmo-pcu patches merged
- Check the other way where UL TBF can be re-established (specs above) and see if it makes sense adding a test for it.
Updated by pespin 10 months ago
- Status changed from Stalled to Resolved
- % Done changed from 70 to 100
The other method to request a new UL TBF at the end of the previous one is used in the setup where PKT CTRL ACK is done doing 4 access bursts, which we don't support in osmo-pcu:
If Control Ack Type parameter in System Information indicates acknowledgement is access burst, the mobile station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message with the Ctrl Ack bits set to '00'.
Hence, it doesn't seem necessary to implement a test for it since there's no rush in implementing that feature, as using an RLC/MAC CTRL block to transmit PKT CTRL ACK as done now is good enough.
