GPRS downlink assignment

After the Immediate assignment, what are you receiving from the MS ?
It is strange that the MS is acknowledging this message, or even sending blocks. It is supposed to be a DL TBF establishment…

On receipt of an Immediate Assignment message, the mobile station stops monitoring downlink CCCH and switches to the assigned PDCH and starts listening for downlink RLC/MAC blocks identified by the assigned DL TFI; it starts timer T3190.

Ok… so what you can check:
– are you sending the data blocks on the correct PDCH ?
– are you using the correct TFI ? TA ?
– is T3190 already expired in MS ?
– is your P.D.Assign in the good format ?

… what else ?

I should have been a bit clearer in the original post.

The Immediate Assign is for an Packet Uplink Assignment in response to a single-phase channel request. Once the PDCH is active I get data blocks on the channel, which is good. Once I’ve got all the data blocks then I acknowledge the data, then the MS stops sending data blocks and sends a Packet Control Acknowledge, which is also good.

What I want to do then, while the PDCH is still allocated, is to allocate a downlink TBF. As I understand it I use a Packet Downlink Assignment for this, but the MS never seems to respond to this.

I think there are two possibilities. One is that there is a timing issue, and the Packet D/L Assignment has to go on a specific block, or has to be sent before the uplink TBF is acknowledged, or something of the sort. The other is that the Packet D/L Assignment message is not formatted correctly, and this is possible although I’ve tried adding and removing parameters, etc., with no success.

If I can rule out any timing issue then I can focus on the message format (and maybe configuration issues).

Dear, CM!
I found out no requirements in 44.060 to send the PACKET CONTROL ACKNOWLEDGEMENT on Packet DL TBF Ass message in packet transfer mode (i.e. when uplink TBF is already assigned). Moreover, to force MS to send PACKET CONTROL ACKNOWLEDGEMENT, a downlink message should contain the poll bit = 1 and the valid RRBP field in its header.

Yes, CM, I agree with you. But we must learn to read between the lines:)
When in 44.060, they discuss Packet DL TBF ASS in packet idle mode (7.2.1.1) they explicitly say that PACKET DOWNLINK ASSIGNMENT on PCCCH is followed by PACKET CONTROL ACKNOWLEDGEMENT (4 access bursts). And PACKET CONTROL ACKNOWLEDGEMENT is used to derive the timing advance.
When they say about Packet DL TBF ASSignment in packet transfer mode on PACCH (8.1.1.1.3) there is no mentioned about PACKET CONTROL ACKNOWLEDGEMENT.
See also Fig. C.1.

Yeah, I looked at C.2 and thought ‘OK, there’s no acknowledgement’ but then C.2 might refer to a DL TBF establishment as a result of an Immediate Assignment, rather than during an existing uplink TBF.

I saw a message flow in an Agilent document earlier today that showed PCA in response to a Packet D/L Assignment, so my plan just now is to focus on the message format, even though I’m sure I’ve tried everything to get it to work so far.

I believe that if the poll bit is set then the acknowledgement should arrive on the frame specified by the RRBP, even if the USF isn’t ‘correct’ for that block. I’m sure I read this recently, though I can’t find a reference right now.

Dear, CM! Who are you asking such strange questions? BSC? PCU? RLC\MAC entity?:) All procedures in question you may seek in 44.060 (for RLC\MAC), 44.018 (for Packet Channel Request and Immediate Ass when there is no PCCCH), 43.064 (for GPRS radiointerface), 45-series (for phisical layer). What else? You also must take in account GPRS BCCH info for MS (e.g. CONTROL_ACK_TYPE etc.) – 24.008 and 44.060.
It is very difficult to understand anything from your description. Give us more info about messages sequences (from beginning) and the key parameters of the messages.