Bug #4558
closedWhy is RRBP set on PACCH Pkt Ul Assignment?
0%
Description
As far as I cant tell from all TTCN3 PCU tests, osmo-pcu sets always RRBP valid (with N+13) requesting a PACKET CTRL ACK when sending a Packet Uplink Assignment through PACCH towards the MS (as can be seen for instance on TC_mt_mo_ping_pong or f_TC_mo_ping_pong_2phase_access).
So far I don't see the point for doing so, since the purpose of setting that is:- During DL data, request DL ACK/NACK
- During UL ACK/NACK, request PKT CTRL ACK to ACK the ACK.
We need to find in the specs if that's needed for some reason (and also check in the code), and if there's no reason for it, then don't set RRBP during Packet Uplink Assignment.
Updated by laforge almost 4 years ago
On Wed, May 20, 2020 at 04:57:48PM +0000, pespin [REDMINE] wrote:
As far as I cant tell from all TTCN3 PCU tests, osmo-pcu sets always RRBP valid (with N+13) requesting a PACKET CTRL ACK when sending a Packet Uplink Assignment through PACCH towards the MS (as can be seen for instance on TC_mt_mo_ping_pong or f_TC_mo_ping_pong_2phase_access).
it's been ages... but don't you want an ACK for the control message (the assignment itself)?
Updated by pespin almost 4 years ago
laforge wrote:
it's been ages... but don't you want an ACK for the control message (the assignment itself)?
Well usually the PCU is already setting USF=X for that X being assigned, which means UL blocks will be received before N+13 anyway. Furthermore, I don't see RRBP being set in any of the flow diagrams in book "GPRS from A to Z".
Updated by pespin almost 4 years ago
There's some references to RRBP in UL Packet Assignment, but when EGPRS is used, not for GPRS:
3GPP TS 44.060 sec 7.1.2.3 Contention resolution at one phase access:
The contention resolution is successfully completed on the mobile station side when the mobile station receives a PACKET UPLINK ACK/NACK message addressing the mobile station with the TFI value associated with the uplink TBF and including the same TLLI value that the mobile station has included in the RLC header of the first RLC data blocks, or alternatively, in EGPRS TBF mode, a PACKET UPLINK ASSIGNMENT message addressing the mobile station with the TFI value associated with the uplink TBF and including the same TLLI value that the mobile station included in the RLC header of the first RLC data blocks. The mobile shall then stop timer T3166 and counter N3104. The contention resolution has failed on the mobile station side when the counter N3104 reaches its maximum value, or timer T3166 expires. The contention resolution also fails, if the mobile station receives a PACKET UPLINK ACK/NACK message or in EGPRS TBF mode alternatively a PACKET UPLINK ASSIGNMENT message addressing the mobile station with the TFI associated with the uplink TBF and including a TLLI value other than that the mobile station included in the RLC header of the first RLC data blocks; in such a case, the mobile station shall not transmit a PACKET CONTROL ACKNOWLEDGEMENT in the uplink radio block specified if a valid RRBP field is received as part of the PACKET UPLINK ACK/NACK message or in EGPRS TBF mode alternatively as part of the PACKET UPLINK ASSIGNMENT message.
I couldn't find any reference on why it may be useful when sending PACCH Pkt Ul Assignment for GPRS.
Updated by pespin over 2 years ago
- Status changed from New to Rejected
After refactoring a lot of code, it now becomes more clear (reference TS 44.060 9.3.3.3.2). The idea is that when a UL TBF finishes sending data (CV=0), network sends UL ACK/NACK with FinalACK=1 and RRBP and then MS can re-establish new TBF when sending the answer on RRBP, by sending a PktResourceReq. Then network will answer with a Pkt Ul Ass (with RRBP set), and will keep this new TBF in ASSIGN state until the CTRL ACK is received, hence the TBF is not really polled for data using USF until it has confirmed the Pkt Ul Ass.
Also related:
7.3.1.4 Abnormal cases If the PACKET UPLINK ASSIGNMENT message contains faulty parameters, the mobile station shall abort the packet access procedure and return to packet idle mode or MAC-Idle state. The measurement report initiating the packet access shall be discarded.
