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

GPRS downlink assignment

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #57562
    CM
    Guest

    I’m trying to get a GPRS downlink TBF established. The cell has no PCCCH.

    I assign the PDCH using AGCH and the handset sends me blocks of data, which is good. I can build the PDU and I can acknowledge the uplink TBF, which is also good. The phone stop sending data and sends a Packet Control Ack which is all good as well.

    But… according to 3GPP specs I should be able to send a Packet Downlink Assignment to establish a downlink TBF. When I send this I don’t get an acknowledgement back.

    If I send the assignment then send downlink data blocks I don’t ever get a Packet Downlink Ack, so I don’t think the downlink assignment is being received by the handset.

    The RX and TX paths are OK (BER test verifies this), and I’ve tried many variations of the Packet Downlink Assignment message in case it’s some parameter that’s wrong / missing.

    So I’m wondering: (a) should I get an Packet Control Ack for a Packet Downlink Assignment message? (b) is there some restriction (e.g. only specific blocks) that I can use to send downlink control messages?

    #57563
    Pix
    Guest

    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 ?

    #57564
    krish
    Guest

    hi,

    by increasing t3190 can we improve the dl multislot assignment?

    #57565
    CM
    Guest

    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).

    #57566
    Pix
    Guest

    CM,

    yes, clearer 1st post would have been great 🙂

    now it’s too late, i left work today, so i can’t help… perhaps tomorrow or friday.

    bye,
    pix

    #57567
    Pan
    Guest

    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.

    #57568
    CM
    Guest

    44.060, 10.4.5, does say ‘The RRBP value specifies a single uplink block in which the mobile station shall transmit either a PACKET CONTROL ACKNOWLEDGEMENT message or a PACCH block to the network. If the RRBP field is received as part of an RLC/MAC block containing an RLC/MAC control block, the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGEMENT message in the uplink radio block specified, except if:
    – The received message is a Packet Paging Request, Packet Access Reject, or Packet Queueing Notification message, or
    – It is specified elsewere that the mobile station shall not respond to the polling request.’

    The ‘specified elsewhere’ part isn’t helpful: it turns the whole thing into ‘you might not get a packet control ack.’ If ‘elsewhere’ was well defined, i.e. if there was a list of control messages that don’t result in a PCA, then this would be simpler.

    #57569
    Pan
    Guest

    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.

    #57570
    Pan
    Guest

    …and C.2

    #57571
    CM
    Guest

    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.

    #57572
    Pix
    Guest

    if you set RRBP = 3, it means that the MS is going to send the PDAN (packet dl ack/nack) in the the third UL block, starting from now.

    “3” is the only available value in alcatel system, so it’s a safe bet to use this value.

    On your side (MFS to MS), it means that the USF specified in the third DL block from now should be set to … errr… 0 ? now i’m not sure anymore… is there a special usf value to allow the MS to send a PDAN ? I’ll let you check it out.

    #57573
    CM
    Guest

    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.

    #57574
    CM
    Guest

    Progress has been made, but there is still some confusion.

    If I send the Packet Downlink Assignment before the Packet Uplink Ack then it is always ignored. That makes some sense, since the MS doesn’t know, until the PUA, if there are any contention issues so it won’t do anything without that confirmation.

    The PUA is always acked with a PCA. As for the PDA:

    If I send one PDA after the PUA then nothing happens.
    If I send two PDAs after the PUA then nothing happens.
    If I send three PDAs after the PUA then all three PDAs are acked with PCAs.

    I tried mixing in some Packet Polling Requests. If I send:

    PPR PPR PDA : no acks
    PPR PPR PDA PDA PDA : no acks
    PDA PDA PDA PPR PPR PPR : all the PDAs are acked, then all the PPRs are acked as well.

    Can anyone shed any light on why I need to send three PDAs before I get them acknowledged??

    #57575
    Pan
    Guest

    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.

    #57576
    CM
    Guest

    This is the message sequence:

    1. MS sends channel request (one-phase data) on RACH
    2. Network sends Immediate Assignment on AGCH, Uplink PDCH
    3. MS sends sequence of RLC/MAC data blocks on assigned PDTCH
    4. Network sends PUA on PACCH
    5. MS sends PCA to ack the PUA

    This is fine so far. Then:

    6. Network sends PDA on PACCH.

    This is where there is confusion. If the network sends one or two PDAs then there is no PCA back. If it sends three PDAs then it gets three PCAs back.

    Some key parameters are:
    Uplink assignment is dynamic.
    USF granularity is 4 blocks.
    USF is 0.
    The timeslot is dedicated to this MS, so all bursts have USF 0 on them.
    RRBP is 1, though changing this doesn’t seem to change anything.
    All control acks are by normal burst rather than access burst.

    Everything behaves as expected, except for the need for three PDAs before I get a PCA. I can’t find any reason for that in the specs, and if anyone has any clue why the phone behaves this way then I’d be interested to find out.

Viewing 15 posts - 1 through 15 (of 17 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.